Kubernetes räumt seinen CVE-Feed auf: Drei Lücken bleiben für immer offen
Seit dem 1. Juni melden Schwachstellenscanner in vielen Kubernetes-Clustern drei alte CVEs, die vorher als behoben galten. Ihr Cluster ist dadurch nicht unsicherer geworden. Wir zeigen, was hinter den Befunden steckt und wie Sie sie für NIS2- und ISMS-Audits sauber dokumentieren.
Was ist passiert?
Am 26. Mai 2026 hat das Kubernetes Security Response Committee (SRC) im offiziellen Kubernetes-Blog eine Korrektur angekündigt, die seit dem 1. Juni umgesetzt ist. Die CVE-Einträge für drei ältere Schwachstellen enthielten fälschlich eine „behobene Version“. Tatsächlich gibt es für sie keinen Fix, und es wird auch keinen geben. Laut SRC handelt es sich um architektonische Abwägungen, die sich nicht per Code beseitigen lassen, ohne grundlegende Kubernetes-Funktionen zu brechen.
- CVE-2020-8561 (CVSS 4.1): Der kube-apiserver folgt HTTP-Weiterleitungen von Admission Webhooks. Wer Webhook-Konfigurationen anlegen darf, kann das ausnutzen. Ein Verbot würde Standardverhalten brechen, auf das viele Integrationen angewiesen sind.
- CVE-2020-8562 (CVSS 3.1): Eine Race Condition bei der DNS-Auflösung erlaubt es, IP-Beschränkungen des API-Server-Proxys zu umgehen. Ein Fix würde komplexe DNS-Setups wie Split-Horizon brechen.
- CVE-2021-25740 (CVSS 3.1): Wer Endpoints oder EndpointSlices schreiben darf, kann LoadBalancer oder Ingress auf Backends in anderen Namespaces lenken. Das ist eine Grundfunktion, die viele Netzwerk-Tools nutzen.
Zusätzlich erhielt CVE-2020-8554, das bereits als „alle Versionen betroffen“ geführt wurde, ein standardisiertes Versionsformat.
Warum betrifft Sie das?
Scanner gleichen Versionsnummern mit CVE-Datenbanken ab. Bisher galt ein Cluster ab der vermeintlich korrigierten Version als sauber. Jetzt tauchen die Befunde auch dort auf, wo vorher nichts gemeldet wurde. Das SRC begründet die Korrektur damit, dass falsche Angaben zu behobenen Versionen eine trügerische Sicherheit erzeugen.
Das Risiko selbst ist nicht neu, es ist nur sichtbar geworden. Für Audits nach NIS2 oder ISO 27001 ist ein offener Befund ohne Patch trotzdem erklärungsbedürftig. Prüfer erwarten eine dokumentierte Entscheidung: Risiko akzeptiert, Gegenmaßnahme umgesetzt, Wirksamkeit regelmäßig geprüft.
Besonders genau sollten Sie Cluster betrachten, die von einer Version vor 1.22 aktualisiert wurden. Seit Kubernetes 1.22 enthalten die Standardrollen edit und admin keine Schreibrechte auf Endpoints mehr. Das gilt laut SRC aber nur für neu erstellte Cluster, ältere können die breiten Rechte noch tragen.
Was Sie jetzt tun sollten
- Bestandsaufnahme: Erfassen Sie, welche Cluster die vier CVEs melden, getrennt von der Frage der Gegenmaßnahmen.
- Endpoints-Schreibrechte prüfen (CVE-2021-25740), vor allem bei älteren Clustern:
kubectl get clusterrole system:aggregate-to-edit -o yaml | grep -E -A6 "endpoints|endpointslices"
kubectl auth can-i create endpointslices -n <namespace> --as=system:serviceaccount:<namespace>:<serviceaccount>
- Webhook-Konfigurationen auditieren (CVE-2020-8561): Prüfen Sie, welche Webhooks existieren und wer sie anlegen darf.
kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations
kubectl auth can-i create validatingwebhookconfigurations --as=<benutzer>
- API-Server härten: Bei selbst betriebenen Clustern die Log-Stufe (
--v) unter 10 halten und--profiling=falsesetzen. Gegen CVE-2020-8562 empfiehlt das SRC einen lokalen DNS-Cache wie dnsmasq auf den Control-Plane-Nodes. - Managed Kubernetes klären: Bei AKS, EKS oder GKE verantwortet der Anbieter die API-Server-Einstellungen. Dokumentieren Sie, welche Kontrollen beim Anbieter liegen und welche bei Ihnen.
- Risikoakzeptanz dokumentieren: Legen Sie je CVE einen Eintrag im Risikoregister an: betroffene Cluster, Begründung mit Link auf den Kubernetes-Blog, umgesetzte Gegenmaßnahme als Kontrolle, verantwortliche Person, Prüfintervall und Nachweis, etwa die Ausgabe der Befehle oben.
- Scanner-Ausnahme erst danach: Unterdrücken Sie den Befund erst, wenn die Dokumentation steht, mit Verweis auf den Registereintrag und einem Ablaufdatum für die erneute Prüfung.
- Vorsichtig ändern: Testen Sie RBAC-Anpassungen zuerst in einem Nicht-Produktionscluster. Laut SRC können sie internes Networking beeinträchtigen.
Fazit
Die neuen Scanner-Befunde sind kein Grund zur Panik, aber ein Anlass zur Ordnung. Wer die Gegenmaßnahmen umsetzt und die Risikoakzeptanz sauber dokumentiert, steht im nächsten Audit besser da als mit einem stillschweigend unterdrückten Alarm. Wenn Sie Unterstützung bei Härtung oder Audit-Dokumentation wünschen, sprechen Sie uns an.