Zurück

2026/11/10

Kyverno CVE-2026-124440: Wenn die Policy-Engine zum Umweg zu Cluster-Admin-Rechten wird

In Kyverno 1.19.1 kann ein Tenant, der in einem Namespace Policies schreiben darf, Cluster-Admin werden. Wie die Umgehung funktioniert und was zu prüfen ist.

Viele Teams setzen Kyverno ein, um Tenants in Kubernetes voneinander zu trennen. Kyverno prüft jedes Objekt anhand von Policies, bevor der API-Server es speichert, und kann Namespace-Verantwortlichen erlauben, eigene Policies für ihren eigenen Namespace zu schreiben. CVE-2026-124440, veröffentlicht am 8. November 2026, zeigt, wie diese Delegation scheitern kann. In Kyverno 1.19.1 kann ein Tenant, der nur in seinem eigenen Namespace Policies anlegen darf, Kyverno dazu bringen, außerhalb dieses Namespace zu handeln, und sich Schritt für Schritt Cluster-Admin-Rechte verschaffen.

Die Korrektur ist seit dem 20. Oktober in Kyverno 1.19.2 verfügbar. Cluster, die dieses Release ausgelassen haben, sind weiterhin angreifbar. Dieser Artikel erklärt, was schiefgelaufen ist, wie die Rechteausweitung abläuft und was Sie in Ihren eigenen Clustern prüfen sollten.

Das Wichtigste in Kürze

  • CVE-2026-124440 (GitHub-Advisory GHSA-39w8-hv5g-f73w) betrifft Kyverno 1.19.1. Behoben ist sie in 1.19.2. Der CVE-Eintrag bewertet sie mit 9.4 nach CVSS 4.0 und 9.9 nach CVSS 3.1.
  • Der Angreifer benötigt lediglich die Berechtigung, in seinem eigenen Namespace eine namespacebezogene Kyverno-Policy anzulegen.
  • Der apiCall der Policy läuft unter dem ServiceAccount des Kyverno-Admission-Controllers, der andere Namespaces lesen und clusterweite Admission-Webhooks anlegen darf. Dieser Weg führt zu Cluster-Admin-Rechten.
  • Das Advisory nennt keinen Workaround. Aktualisieren Sie auf 1.19.2 und prüfen Sie anschließend, wer Policies anlegen darf und welche Webhooks existieren.
  • In den von uns ausgewerteten Quellen wird keine aktive Ausnutzung gemeldet.

Was die Namespace-Begrenzung leisten sollte

Kyverno-Policies können während der Auswertung einer Anfrage Daten aus der Kubernetes-API abrufen. Diese Funktion heißt apiCall: Eine Regel gibt einen urlPath an, Kyverno ruft den API-Server auf, und das Ergebnis fließt in die Regel ein. Der Aufruf erfolgt mit Kyvernos eigenem ServiceAccount, nicht mit den Berechtigungen der Person, die die Policy geschrieben hat.

Bei clusterweiten ClusterPolicies, die von Plattformadministratoren geschrieben werden, ist das so gewollt. Bei namespacebezogenen Policies, die Tenants unter Umständen selbst schreiben dürfen, ist es ein Risiko. Frühere Advisories (GHSA-c5qq-7g2q-cpqp und GHSA-5qq8-67g6-4h2w) hatten gezeigt, dass eine namespacebezogene Policy über apiCall andere Namespaces lesen oder clusterweite Objekte schreiben konnte. Kyverno 1.19.1, veröffentlicht am 10. September 2026, führte daher eine „Namespace-Begrenzung“ (Namespace Clamp) ein: Bevor der Aufruf ausgeführt wird, prüft Kyverno, ob der Pfad innerhalb des Namespace der Policy bleibt.

Wo Prüfung und Ausführung auseinanderlaufen

Die Begrenzung in 1.19.1 prüfte nicht die Zeichenkette, die tatsächlich gesendet wurde. Laut Advisory dekodierte sie die Prozentkodierung in urlPath, normalisierte das Ergebnis (sodass ..-Segmente aufgelöst werden) und prüfte den Namespace in dieser bereinigten Kopie. Die eigentliche Anfrage wurde dann jedoch mit dem ursprünglichen, unveränderten Pfad gesendet.

Das funktioniert, solange die Dekodierung gelingt. Enthält der Pfad aber eine fehlerhafte Prozent-Escape-Sequenz, etwa ein einzelnes % in einem nachgestellten Query-String, schlägt die Dekodierung fehl. In diesem Fall wich der Code in 1.19.1 darauf aus, die rohe, noch kodierte Zeichenkette zu prüfen. Der API-Server kennt keinen solchen Ausweichpfad. Er dekodiert den Pfad vollständig und leitet die Anfrage weiter. Die Begrenzung sieht also den eigenen Namespace des Tenants, während der API-Server kodierte ..-Segmente sieht, die aus ihm herausführen – in einen anderen Namespace oder zu einer clusterweiten Collection.

Das Advisory betont, dass es sich um eine ganze Klasse von Eingaben handelt, nicht um eine einzelne Payload. Eine bestimmte Zeichenkette zu blockieren, würde die Lücke nicht schließen. Die nachhaltige Lösung besteht darin, genau denselben Pfad zu validieren und auszuführen.

Genau das tut 1.19.2. Nach unserer Lektüre des Quellcodes von 1.19.2 erzeugt Kyverno nun eine einzige kanonische Form des Pfads, lehnt Pfade ab, die sich nicht kanonisieren lassen, prüft den Namespace anhand dieser Form und sendet genau diese Form an den API-Server. Ein verwandtes Problem, das im selben Release behoben wurde, CVE-2026-122310 (GHSA-3xfv-vq8x-qhg4), nutzte dieselbe Diskrepanz zwischen der Prüfung der bereinigten Kopie und der rohen Anfrage aus, indem es ../-Segmente hinter # oder ? versteckte. Es handelt sich um eine eigene CVE mit eigenem Eintrag.

Die Kette der Rechteausweitung, Schritt für Schritt

Der Melder demonstrierte die Kette auf Kubernetes 1.31 mit Kyverno 1.19.1, installiert aus dem Standard-Helm-Chart mit Standardwerten.

  1. Eine namespacebezogene Policy anlegen. Das einzige Privileg des Tenants besteht darin, policies.kyverno.io in seinem eigenen Namespace anzulegen. Die Policy enthält einen apiCall, dessen Pfad die Begrenzung passiert, aber an ein anderes Ziel geleitet wird.
  2. Die Policy auslösen. Wird ein beliebiges gewöhnliches Objekt angelegt, auf das die Policy zutrifft, etwa eine ConfigMap im Namespace des Tenants, wertet Kyverno die Regel aus und führt den Aufruf unter dem ServiceAccount seines Admission-Controllers aus.
  3. Namespace-übergreifend lesen. Mit derselben Technik lassen sich Objekte in anderen Namespaces lesen, einschließlich Secrets, sofern das Kyverno-Deployment diese lesen darf.
  4. Einen clusterweiten Webhook schreiben. Der ServiceAccount darf MutatingWebhookConfigurations und ValidatingWebhookConfigurations anlegen. Der Tenant kann daher einen eigenen Webhook registrieren, der anschließend Admission-Anfragen in allen Namespaces abfängt und umschreibt.
  5. Cluster-Admin-Rechte erlangen. Das Advisory beschreibt, wie ein solcher Webhook genutzt wird, um in kube-system erstellte Pods zu verändern und dem Tenant von dort aus cluster-admin-Rechte zu verschaffen. Das Ergebnis ist ein vollständiger Verlust von Vertraulichkeit, Integrität und Verfügbarkeit.

Es ist keine Benutzerinteraktion erforderlich, und der Webhook wird bei normaler Clusteraktivität ausgelöst.

Wer betroffen ist

Der CVE-Eintrag führt Kyverno 1.19.1 als betroffen und 1.19.2 als nicht betroffen. Versionen vor 1.19.1 weisen diese spezielle Umgehung nicht auf, weil sie überhaupt keine Namespace-Begrenzung haben. Sie sind jedoch von den früheren Advisories betroffen, die die Begrenzung beheben sollte; bei einer älteren Version zu bleiben, ist daher keine sichere Alternative. Am höchsten ist das Risiko dort, wo Namespace-Verantwortliche, CI-Pipelines oder Self-Service-Portale Kyverno-Policies anlegen dürfen.

Kyverno 1.19.2 wurde am 20. Oktober 2026 veröffentlicht, und die Release Notes führen 24 GitHub-Sicherheits-Advisories auf: 9 kritische, 14 hohe und 1 mittleres. Mehrere davon betreffen die Validierung von API-Pfaden und die Beschränkung auf Namespaces. Dieses Advisory wurde drei Tage später, am 23. Oktober, veröffentlicht, doch sowohl das Advisory als auch der CVE-Eintrag nennen 1.19.2 als korrigierte Version. Jedes Advisory hat eine eigene Kennung. Gleichen Sie sie daher einzeln ab, statt die gesamte Gruppe als eine einzige CVE zu behandeln.

Was Sie in Ihren eigenen Clustern prüfen sollten

Ermitteln Sie zuerst die Kyverno-Version, die tatsächlich läuft, nicht die in Ihrem Git-Repository:

kubectl get deployments -n kyverno -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.template.spec.containers[*].image}{"\n"}{end}'

Lautet ein Image-Tag v1.19.1, planen Sie das Upgrade auf 1.19.2 jetzt ein. Prüfen Sie dann vier Punkte:

  • Wer namespacebezogene Policies anlegen darf. Testen Sie die Identitäten der Tenants direkt und suchen Sie nach Rollen, die policies.kyverno.io gewähren, einschließlich aggregierter ClusterRoles, die den integrierten Rollen admin und edit Rechte hinzufügen.
  • Bestehende Policies, die apiCall verwenden. Listen Sie sie auf und prüfen Sie jeden urlPath, insbesondere Pfade, die %, .., ? oder # enthalten.
  • Webhook-Konfigurationen. Vergleichen Sie die Liste mit dem erwarteten Bestand. Kyverno legt eigene Webhooks an; achten Sie daher vor allem auf Namen, die Sie nicht kennen, und auf kürzlich erfolgte Erstellungen.
  • Audit-Logs. Suchen Sie nach Anfragen des ServiceAccounts des Kyverno-Admission-Controllers, die Webhook-Konfigurationen anlegen oder Secrets außerhalb des üblichen Musters lesen.
kubectl auth can-i create policies.kyverno.io -n team-a --as=system:serviceaccount:team-a:default
kubectl get policies.kyverno.io -A -o json | jq -r '.items[] | select([.spec.rules[]?.context[]? | select(.apiCall)] | length > 0) | "\(.metadata.namespace)/\(.metadata.name)"'
kubectl get mutatingwebhookconfigurations,validatingwebhookconfigurations -o custom-columns=NAME:.metadata.name,CREATED:.metadata.creationTimestamp

Ersetzen Sie team-a durch Ihre eigenen Tenant-Namespaces und -Identitäten. Finden Sie auf einem Cluster, auf dem 1.19.1 lief, einen Webhook, den Sie nicht erklären können, behandeln Sie dies als möglichen Sicherheitsvorfall: Sichern Sie die Audit-Logs, bevor Sie irgendetwas entfernen.

Die übergreifende Lehre: Auch die Kontrollinstanz prüfen

Admission-Controller, Policy-Engines und Operatoren gehören oft zu den Komponenten mit den meisten Rechten in einem Cluster. Sie brauchen weitreichende Berechtigungen für ihre Aufgabe, und Tenants interagieren täglich mit ihnen. Das macht sie zu einem attraktiven Ziel. In diesem Fall hing das Mandantenmodell von einer einzigen Prüfung ab, und ein einziger Dekodierungsschritt, den Prüfung und Anfrage unterschiedlich behandelten, reichte aus, um es auszuhebeln.

Für Private-Cloud- und mandantenfähige Kubernetes-Plattformen helfen drei Gewohnheiten. Betrachten Sie Policy-Engines als Teil der Angriffsfläche und verfolgen Sie ihre Sicherheitsreleases ebenso genau wie die Kubernetes-Version. Geben Sie ihren ServiceAccounts nur die Rechte, die sie benötigen, und gewähren Sie beispielsweise keinen Lesezugriff auf Secrets, sofern keine Policy ihn erfordert. Und prüfen Sie, welche Funktionen Tenants über Delegation erreichen können: Eine Funktion, die mit den Privilegien der Plattform läuft, macht aus der Eingabe eines Tenants eine Aktion der Plattform.

Quellen