Kritische Kyverno-Lücke erlaubt Policy-Bypass über PolicyExceptions

Kurzfassung

Kyverno hat eine kritische Schwachstelle bei der Behandlung von PolicyExceptions. Wer Versionen von v1.9.0 bis v1.12.7 einsetzt, kann unter bestimmten Bedingungen eine eigentlich erzwungene Policy umgehen. Ein Update auf v1.13.0 behebt das Problem.

Für Kubernetes-Umgebungen ist das relevant, wenn Kyverno zur Durchsetzung von Sicherheitsvorgaben genutzt wird. Dann kann ein Angreifer mit passend benannten Ressourcen Kontrollen aushebeln, etwa Regeln gegen hostPath-Volumes.

Was ist passiert?

Die Lücke steckt in der Auswertung von PolicyExceptions. Kritisch wird es, wenn eine Policy im Enforce-Modus mit zwei Ausnahmen kombiniert wird. In diesem Fall kann die weniger restriktive Ausnahme Vorrang bekommen. Ein Angreifer kann das ausnutzen, indem er eine Ressource so benennt, dass sie zum Namensmuster der zweiten Ausnahme passt.

Das ist kein theoretisches Detail für die Fußnote. Wer Kyverno als Kontrollinstanz vor seinen Clustern betreibt, verlässt sich darauf, dass Ausnahmen sauber und eindeutig greifen. Genau dort bricht die Logik.

Technische Details

CVE-2026-84200 ist als kritisch eingestuft. Laut NVD betrifft die Schwachstelle Kyverno in den Versionen v1.9.0 bis v1.12.7. Die korrigierte Version ist v1.13.0.

Der Angriffsweg braucht keine exotische Komponente. Entscheidend ist die Kombination aus Enforce-Policy und zwei PolicyExceptions. Wenn die zweite Ausnahme über ein Namensmuster wie *ingress* greift, kann das die strengere Regel aushebeln. Damit lassen sich Vorgaben umgehen, die eigentlich etwa hostPath-Volumes blockieren sollen.

Ob andere Policy-Konstellationen ebenfalls angreifbar sind, bleibt in der Quelle offen. Ebenso nennt die Quelle keinen CVSS-Wert, nur die Einstufung als kritisch.

Wer ist betroffen?

Betroffen sind vor allem Teams, die Kyverno in Kubernetes-Clustern produktiv einsetzen. Das gilt in Rechenzentren, in privaten Clouds und in Managed-Kubernetes-Setups gleichermaßen. Für klassische Endanwender ist das Thema kaum relevant.

Wer Policies nur testweise nutzt oder keine PolicyExceptions konfiguriert hat, dürfte deutlich weniger Risiko tragen. Anders sieht es aus, wenn Sicherheitsregeln im Cluster zentrale Freigaben, Laufzeitverbote oder Compliance-Vorgaben absichern.

Empfohlene Maßnahmen

Priorität eins: auf v1.13.0 aktualisieren. Das ist die saubere Lösung und sollte in allen Umgebungen mit aktivem Kyverno-Paket auf die Agenda.

Bis das Update eingespielt ist, sollten Admins alle PolicyExceptions prüfen. Besonders relevant sind Regeln mit mehreren Ausnahmen und Policies im Enforce-Modus. Wer dort lockere Namensmuster verwendet, sollte sie vorübergehend verschärfen oder die betroffene Policy anders schneiden.

Prüfen Sie außerdem, ob kritische Sicherheitsregeln wie hostPath-, Privileged- oder Namespace-bezogene Vorgaben über Kyverno abgesichert werden. Genau solche Kontrollen sind bei einem Bypass gefährlich, weil der Angriff dann direkt an der Schutzschicht ansetzt.

Offizielle Details und den Fix nennt die NVD-Quelle unter https://nvd.nist.gov/vuln/detail/CVE-2026-84200.

Einschätzung von CyberSecurity-News.de

Die Schwachstelle ist ernst, aber ihr praktischer Schaden hängt stark von der Konfiguration ab. Wer Kyverno ohne PolicyExceptions oder ohne harte Enforce-Regeln betreibt, hat weniger Grund zur Panik. Wer dagegen bewusst mit Ausnahmen arbeitet, sollte jetzt prüfen, ob die Logik im Cluster noch dem gewünschten Sicherheitsniveau entspricht.

Unschön ist vor allem die Angriffsstelle: Ausnahmen sind in Sicherheitsprodukten immer ein sensibles Thema, weil sie Schutzregeln faktisch relativieren. Genau deshalb darf die Kommunikation dazu nicht bei einer knappen CVE-Notiz stehen bleiben. Admins brauchen klare Hinweise, welche Policy-Kombinationen gefährdet sind und wie sie die Übergangszeit absichern.

Fazit

CVE-2026-84200 ist ein klassischer Fall von „Sicherheitsregel vorhanden, aber umgehbar“. Das betrifft vor allem Kubernetes-Teams, die Kyverno produktiv zur Härtung ihrer Cluster einsetzen. Wer zu den Betroffenen gehört, sollte das Update auf v1.13.0 nicht schieben.

Bis dahin gilt: Policies mit Ausnahmen genau ansehen, riskante Muster entschärfen, und den Cluster nicht auf das Versprechen der Kontrollschicht allein verlassen.