Fehler 9,9 in OpenShift Virtualization ermöglicht es einem Benutzer eines Namespaces, den Host zu übernehmen (CVE-2026-7374)
Ein Schwachstelle im virt-handler von KubeVirt ermöglicht es einem Benutzer mit Bearbeitungsrechten in einem einzigen Namespace, den CRI-O-Socket zu kapern und den gesamten Knoten zu gefährden. Red Hat hat für die Versionen ab 4.12 Sicherheitsbulletins veröffentlicht.
Ein Benutzer mit Bearbeitungsberechtigung in einem einzigen Namespace von OpenShift kann in den Host entkommen und den gesamten Knoten gefährden. Red Hat veröffentlichte am 26. Mai die CVE-2026-7374, einen Fehler im virtuellen Handler von KubeVirt, der OpenShift Virtualization (ehemals Container Native Virtualization) unterstützt, mit einem CVSS-Wert von 9,9, nur einen Zehntel vom Maximum der Skala entfernt.
Der Bruch der Grenze zwischen Namespace und Host
Das Problem liegt in einer laxen Validierung von Symlinks, wenn der virt-handler sich mit den Konsolen-Sockets der virtuellen Maschinen verbindet. Laut Red Hat kann ein authentifizierter Benutzer von OpenShift mit Bearbeitungsberechtigung in einem Namespace den Konsolen-Socket durch einen symbolischen Link ersetzen, der auf den Socket des Container-Runtimes des Hosts, den CRI-O, zeigt. Dadurch wird die privilegierte Verbindung des virt-handlers gekapert und jeder Unix-Socket des Hosts kann erreicht werden, was den Weg für die vollständige Kontrolle über den Knoten öffnet. Die Klassifizierung ist CWE-787 für unsachgemäße Auflösung von Links vor dem Datei zugriff, ein altes Problem, bei dem man einen Shortcut folgt, ohne zu überprüfen, wohin er zeigt.
Der Angriffsvektor erklärt, warum der Wert 9,9 erreicht. Der Angriff erfolgt über das Netzwerk (AV:N), hat eine niedrige Komplexität (AC:L), erfordert nur geringe Berechtigungen (PR:L) und keine Benutzerinteraktion (UI:N). Der entscheidende Punkt ist der geänderte Geltungsbereich (S:C): die Ausnutzung beginnt innerhalb eines Namespaces und endet außerhalb davon, im Host. Vertraulichkeit, Integrität und Verfügbarkeit fallen alle auf hohen Einfluss. In einem Multi-Tenant-Cluster bedeutet dies, dass das Credential mit den geringsten Berechtigungen innerhalb eines isolierten Raums der Schlüssel zum gesamten Stockwerk wird.
Was an diesem Arrangement beunruhigt, ist die Größe der Voraussetzung. Es handelt sich nicht um einen Cluster-Administrator oder Zugriff auf das Kontrollpanel: Es genügt, Bearbeitungsrechte in einem Namespace zu haben, das Level, das Entwicklungs-Teams gewährt wird, um ihre eigenen virtuellen Maschinen zu verwalten. In Clustern, die Dutzende von Teams beherbergen, ist die Population, die dieses Kriterium erfüllt, groß, und jedes Dienstkonto mit diesen Rechten wird zu einem möglichen Angriffsvektor. Der Angriff erfordert auch kein Timing oder soziale Technik, da der Vektor null Benutzerinteraktionen verlangt.
Warum es diejenigen betrifft, die von VMware gewechselt sind
Das Timing ist entscheidend. Seit Broadcom die VMware-Lizenzierung auf teurere Abonnierungspakete umgestellt hat, haben viele Unternehmen nach Alternativen gesucht, und OpenShift Virtualization hat sich als eines der Ziele etabliert, um virtuelle Maschinen zusammen mit Containern auf derselben Plattform auszuführen. Das zentrale Versprechen dieser Migration ist Konsolidierung mit Isolation: mehrere Teams oder mehrere Kunden, die dasselbe Cluster unter den Grenzen von Namespaces gemeinsam nutzen.
Die CVE-2026-7374 zielt genau auf dieses Versprechen ab. Ein Fehler, der von einem Namespace zum Host reicht, ist kein technisches Detail: Es ist die Aufhebung des Multi-Tenant-Modells, das die Konsolidierung rechtfertigt. Die Patches wurden in einer Reihe von Sicherheitsbulletins von Red Hat veröffentlicht, darunter RHSA-2026:20720, RHSA-2026:20736, RHSA-2026:20763 und RHSA-2026:20782, die die betroffenen Linien ab Version 4.12 abdecken.
Was sich für Brasilien ändert
Die Migration von VMware ist hier nicht abstrakt. Banken, Telekommunikationsanbieter, große Einzelhändler und die öffentliche Verwaltung konzentrieren große Bestände an virtuellen Maschinen und gehören zu denjenigen, die am meisten unter den Lizenzumstellungen gelitten haben. Für diese Unternehmen hat sich OpenShift Virtualization als Ausweg etabliert, und einige von ihnen betreiben bereits Produktivlasten darauf.
Für eine Bank, die interne Systeme auf gemeinsam genutzte Cluster migriert hat, ist die Situation klar: Die Zahl der Teams und Dienstleister mit Bearbeitungszugriff auf einen Namespace ist in der Regel groß, und jede dieser Identitäten hat über Nacht einen theoretischen Weg zum Host erhalten. Das Risiko kommt nicht von einem anonymen externen Angreifer; es kommt von einem Insider, einem externen Dienstleister oder einer gehackten Identität mit geringen Rechten, die plötzlich viel mehr wert ist als ursprünglich angenommen.
Die sinnvolle Antwort kombiniert den Patch mit einer Überprüfung, wer wirklich Bearbeitungsrechte in jedem Namespace benötigt. Die Migration weg von einem teuren Hypervisor hat Lizenzkosten eingespart; was diese Schwachstelle erinnert, ist, dass die Sicherheitsrechnung der neuen Plattform in einer anderen Währung kommt, nämlich in der Strenge darüber, wer was innerhalb des Clusters anfassen darf.