Kurzfassung
Gleich fünf Schwachstellen verdienen Aufmerksamkeit, auch wenn sie fachlich aus zwei sehr unterschiedlichen Ecken kommen. Drei betreffen Cluster- und Multicloud-Komponenten rund um Submariner, Lighthouse und das multicloud-operators-subscription-Framework. Zwei ältere Red-Hat-Lücken stehen seit Jahren in CISA KEV und werden laut CISA aktiv ausgenutzt: CVE-2015-3246 und CVE-2015-5287.
Für Unternehmen im DACH-Raum ist die Lage klar: Wer Kubernetes-Cluster über mehrere Umgebungen hinweg koppelt oder Red-Hat-Systeme mit älteren Paketen betreibt, sollte sofort prüfen, ob die betroffenen Komponenten überhaupt im Einsatz sind. Die drei neuen CVEs sind als kritisch eingestuft. Bei den beiden alten geht es nicht um Theorie, sondern um real beobachtete Angriffe auf lokal verwundbare Systeme.
Was ist passiert?
Die erste Gruppe betrifft Submariner und Lighthouse, zwei Bausteine für verteilte Cluster-Umgebungen. Bei CVE-2026-66785 kann ein bösartiger Cluster den Netzwerkverkehr anderer verbundener Cluster umlenken, wenn er manipulierte Endpunkte veröffentlicht. Bei CVE-2026-66788 reicht ein kompromittierter Spoke-Cluster offenbar aus, um Ressourcen in Ziel-Namespaces anderer Cluster einzuschleusen. Das Problem sitzt tief im Vertrauensmodell: Das System übernimmt Angaben aus dem Cluster-Umfeld, die es eigentlich härter prüfen müsste.
CVE-2026-67567 zielt auf das multicloud-operators-subscription-Component. Dort kann ein Tenant, der HelmRelease-Objekte anlegen darf, bestehende Schutzmechanismen aushebeln. Der Controller verarbeitet Helm-Templates mit eigenen, erhöhten Rechten. Genau das macht die Sache heikel. Ein zu weit gefasster Tenant-Zugriff kann dann reichen, um clusterweite Ressourcen zu platzieren.
Die beiden Red-Hat-Fälle sind älter, aber operativ weiter relevant. CVE-2015-3246 beschreibt eine Race Condition in libuser, die lokal angemeldete Benutzer zum Korruptieren von /etc/passwd missbrauchen können. Das kann zu Denial of Service oder Privilegienausweitung führen. CVE-2015-5287 betrifft ABRT und erlaubt unter bestimmten Rechten eine Privilegienerhöhung über einen Symlink-Angriff auf eine Datei mit vorhersehbarem Namen. CISA führt beide als aktiv ausgenutzt.
Technische Details
Bei CVE-2026-66785 fehlt die saubere Validierung der vom Angreifer gelieferten Subnetze. Dadurch kann ein fremder Cluster beliebige Netzwerkbereiche deklarieren. Traffic, der an diese Bereiche adressiert ist, läuft dann durch den Tunnel des Angreifers. Das ist mehr als ein Routing-Fehler. Es öffnet die Tür für Mitlesen und Störung.
CVE-2026-66788 nutzt die Art und Weise aus, wie Lighthouse das Ziel-Namespace für eine Ressourcen-Injektion bestimmt. Wenn diese Entscheidung aus einem vom Angreifer kontrollierten Label oder einer Annotation auf einem Broker-Objekt abgeleitet wird, kann ein kompromittierter Spoke-Cluster unangemeldete EndpointSlices und ServiceImports in beliebige Namespaces schreiben. Besonders unangenehm: Auch kube-system und openshift-* sollen betroffen sein können.
Bei CVE-2026-67567 ist das Kernproblem die Rechteverteilung. Der HelmRelease-Controller verarbeitet Vorlagen mit seinem eigenen ServiceAccount und prüft die Inhalte offenbar nicht ausreichend. Wer die passenden CRs anlegen darf, kann dadurch Ressourcen mit deutlich mehr Wirkung erzeugen, als die ursprüngliche Tenant-Rolle eigentlich erlauben sollte.
CVE-2015-3246 und CVE-2015-5287 sind klassische lokale Eskalationslücken. In beiden Fällen braucht der Angreifer bereits Zugriff auf das System. Das macht sie für reine Internet-Exposition weniger interessant, für kompromittierte Server, Jump Hosts oder schlecht gehärtete Mehrbenutzer-Systeme aber sehr wohl.
Wer ist betroffen?
Betroffen sind Organisationen, die Submariner oder Lighthouse für die Verbindung mehrerer Cluster einsetzen, etwa in Kubernetes- oder OpenShift-Umgebungen. Das gilt vor allem für Teams, die Cluster federieren, Netzwerkpfade über mehrere Standorte ziehen oder Mandanten sauber voneinander trennen müssen. Genau dort treffen diese Schwachstellen den Nerv.
Bei CVE-2026-67567 geht es um Umgebungen mit multicloud-operators-subscription und HelmRelease-Nutzung. Wer Tenants Ressourcen anlegen lässt, sollte den Zugriff auf diese CRs sofort überprüfen. Ein offener Tenant-Zugriff ist hier kein harmloses Komfort-Feature, sondern potenziell der Startpunkt für clusterweite Kompromittierung.
Die beiden Red-Hat-Schwachstellen betreffen Systeme mit Red Hat Libuser und Red Hat Automatic Bug Reporting Tool. Laut Quelle können die betroffenen Produkte auch End-of-Life oder End-of-Service sein. Für solche Installationen ist die Lage besonders schlecht, weil sich ein Patchpfad oft nicht mehr sauber ziehen lässt.
Für die meisten Büro-Workloads ohne Cluster-Verbund und ohne alte Red-Hat-Komponenten ist die unmittelbare Relevanz geringer. Wer aber Plattformbetrieb, OT-nahe Umgebungen, Hosting oder interne Cloud-Infrastruktur verantwortet, sollte die Meldung nicht abheften. Hier reden wir über echte Angriffsflächen.
Empfohlene Maßnahmen
Priorität eins: Inventarisieren. Prüfen Sie, ob Submariner, Lighthouse oder multicloud-operators-subscription überhaupt installiert sind und in welchen Versionen. Ohne saubere Bestandsaufnahme bleibt jede Reaktion Stückwerk.
Priorität zwei: Zugriffe einschränken. Bei CVE-2026-67567 sollten nur sehr wenige Rollen HelmRelease-CRs anlegen dürfen. Bei Submariner und Lighthouse lohnt ein Blick auf Cluster-Vertrauen, Namespace-Zuordnung und die Behandlung von Broker-Objekten. Wer dort wild delegiert hat, muss nacharbeiten.
Priorität drei: Patchen oder ersetzen. Für die beiden Red-Hat-Lücken gilt laut CISA, dass Milderungen nach Herstellerhinweis umzusetzen sind. Wenn es keine tragfähigen Mitigations gibt, soll die Nutzung beendet oder auf eine unterstützte Version gewechselt werden. Das gilt besonders für EoL- und EoS-Installationen.
Admins sollten außerdem prüfen, ob die Systeme internetnah erreichbar sind, und die Vorgaben aus CISA BOD 26-04 in ihre Priorisierung einbeziehen. Bei aktiver Ausnutzung zählt nicht die theoretische Schwere, sondern die reale Erreichbarkeit. Genau daran scheitern in der Praxis viele Patch-Entscheidungen.
Einschätzung von CyberSecurity-News.de
Die drei neuen CVEs zeigen ein bekanntes Muster: Zu viel Vertrauen in interne Metadaten und zu großzügige Rechte an Stellen, an denen ein Cluster eigentlich misstrauisch sein müsste. Das ist unsauber gebaut. Gerade in verteilten Kubernetes-Setups rächt sich so etwas schnell, weil ein kompromittierter Teil gleich andere Segmente mitreißen kann.
Die beiden Red-Hat-Fälle sind noch deutlicher einzuordnen. Sie sind alt, aber nicht erledigt. Dass CISA sie als aktiv ausgenutzt führt, macht sie für Betreiber mit Legacy-Bestand relevant. Wer solche Systeme noch im Einsatz hat, sollte sich keine Ausreden suchen. Entweder absichern, aktualisieren oder abschalten.
Unklar bleibt bei den neuen Cluster-Schwachstellen, welche Versionen genau betroffen sind und ob alle Ableger gleichermaßen verwundbar sind. Diese Lücke in der Herstellerkommunikation ist ärgerlich. Für Betreiber heißt das: nicht auf Detailnachreiche warten, sondern den eigenen Bestand jetzt gegenprüfen.
Fazit
CVE-2026-66785, CVE-2026-66788 und CVE-2026-67567 sind für Cluster-Betreiber ernst. Sie betreffen Vertrauensgrenzen, Routing und Rechtevergabe in Umgebungen, in denen ein Fehler schnell weit reicht. Die beiden älteren Lücken CVE-2015-3246 und CVE-2015-5287 erinnern daran, dass alte, lokal ausnutzbare Schwachstellen weiter brandgefährlich bleiben, wenn Systeme nicht konsequent gepflegt werden.
Wer Submariner, Lighthouse, multicloud-operators-subscription oder betagte Red-Hat-Komponenten nutzt, sollte jetzt prüfen, ob Handlungsbedarf besteht. Für alle anderen bleibt die Meldung fachlich relevant, aber nicht akut.
