Öffentlich verfügbarer AF_UNIX-Exploit durchbricht die Ubuntu-Container-Isolation und erreicht Root auf dem Host

Ein öffentlich verfügbarer Exploit für CVE-2026-80521 kann eine eingeschränkte Codeausführung in einem Ubuntu-Container in Root-Rechte auf dem zugrunde liegenden Host umwandeln.

Die Schwachstelle ist ein Use-after-free im Garbage Collector des Linux-Kernels für AF_UNIX-Sockets. Sie lässt sich über gewöhnliche Systemaufrufe auslösen, die von den standardmäßigen Seccomp-Konfigurationen von Docker und Kubernetes zugelassen werden. Dadurch sind die standardmäßigen Container-Schutzmechanismen gegen diesen Angriffsweg wirkungslos.

DepthFirst hat funktionierenden Exploit-Code veröffentlicht, der auf Ubuntu 26.04 abzielt. Bis zum 23. September 2026 wurden keine Angriffe bestätigt, und die Schwachstelle ist nicht im Katalog der bekannten ausgenutzten Schwachstellen der US-amerikanischen Cybersecurity and Infrastructure Security Agency aufgeführt. Daher gibt es keine CISA-Frist für die Behebung.

Der öffentliche Exploit erhöht dennoch das Risiko für Plattformen, auf denen nicht vertrauenswürdige oder nur teilweise vertrauenswürdige Container mit einem gemeinsam genutzten Kernel ausgeführt werden.

Eine Race Condition bei der AF_UNIX-Garbage-Collection ermöglicht den Ausbruch

AF_UNIX-Sockets ermöglichen die lokale Interprozesskommunikation und können offene Dateideskriptoren über SCM_RIGHTS-Nachrichten übertragen. Der Kernel muss die übertragenen Referenzen nachverfolgen und zyklische Gruppen von Sockets zurückgewinnen, die nicht mehr erreichbar sind.

CVE-2026-80521 entsteht durch eine Race Condition innerhalb dieses Garbage-Collection-Prozesses.

Ubuntu schreibt den Bericht Kyle Zeng zu. Die technische Beschreibung verwendet drei Sockets – A, B und X –, um den Ablauf der Race Condition zu erläutern:

1. Die Sockets A und B gehören zu miteinander verknüpften Referenzgruppen, die als stark zusammenhängende Komponenten (Strongly Connected Components, SCCs) bezeichnet werden, während X der Gruppe zugeordnet ist.
2. Gleichzeitig wird sk-B von sk-X an sk-B gesendet und A und B werden geschlossen.
3. Während des Sendevorgangs veröffentlicht unix_add_edges() eine neue Kante, die die Beziehung B zu B repräsentiert.
4. Es gibt ein kurzes Zeitfenster, bevor der Socket-Puffer, der diese Referenz enthält, mit skb_queue_tail() eingefügt wird.
5. Wenn die Schließvorgänge und die Garbage Collection in diesem Zeitfenster stattfinden, kann der Collector die Gruppe A-B als nicht mehr aktiv einstufen.
6. B wird nicht sofort freigegeben, weil der Collector den Socket-Puffer mit der neu veröffentlichten Referenz noch nicht erkennen kann.
7. Ein späterer Durchlauf der Collection folgt scc_entry von B in einen teilweise freigegebenen Zustand.

Das Ergebnis ist ein Use-after-free. Die Korrektur im Upstream mit dem Titel af_unix: Unlink scc_entry in unix_del_edge(). entfernt den internen SCC-Eintrag, bevor der zugehörige Knoten freigegeben wird.

Die Erklärung von DepthFirst kommt zum selben Kernschluss: Der Collector kann eine veröffentlichte Referenz erkennen, bevor er die Datenstruktur sieht, die diese Referenz enthält. Die teilweise Bereinigung hinterlässt anschließend einen dauerhaften Zeiger auf freigegebenen Speicher.

Standardmäßige Container-Schutzmechanismen blockieren die erforderlichen Aufrufe nicht

Die Schwachstelle erfordert keinen Remotezugriff auf den Host. Ein Angreifer benötigt lediglich einen lokalen Ausführungskontext mit niedrigen Rechten, etwa die Kontrolle über einen Prozess innerhalb eines Containers.

Diese Voraussetzung spiegelt sich in der hohen CVSS-Bewertung von 7,8 und dem Vektor wider:

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Der Angriff weist eine geringe Komplexität auf, erfordert geringe Berechtigungen und keine Interaktion des Benutzers. Eine erfolgreiche Ausnutzung kann die Vertraulichkeit, Integrität und Verfügbarkeit des Hosts gefährden.

AF_UNIX-Socket-Operationen sind innerhalb von Containern normalerweise verfügbar. Die Seccomp-Profile von Docker und Kubernetes erlauben die relevanten Schnittstellen standardmäßig, sodass der Exploit keine ungewöhnliche oder bewusst zu weit gefasste Konfiguration voraussetzt.

Sobald der Speicherfehler im Kernel ausgenutzt wurde, können Namespaces, cgroups und Seccomp-Filter die vorgesehene Sicherheitsgrenze nicht mehr aufrechterhalten. Diese Mechanismen isolieren Prozesse, verwenden dabei aber weiterhin denselben Host-Kernel. Eine Kompromittierung des Kernels erfolgt unterhalb dieser Schutzschicht.

Dieser Unterschied ist für mandantenfähige Dienste, CI/CD-Runner, containerbasierte Entwicklungsumgebungen und Systeme zur Ausführung von kundenseitig eingereichtem Code von Bedeutung. Ein Prozess, der auf einen einzelnen Container beschränkt sein sollte, kann stattdessen Root-Kontrolle über den Host erlangen und möglicherweise weitere darauf ausgeführte Workloads beeinträchtigen.

Die Betroffenheit von Ubuntu hängt vom installierten Kernel-Paket ab

Ubuntus Security-Tracker auf Paketebene ermöglicht eine präzisere Einschätzung als die Versionsnummer des Betriebssystems allein.

Das grundlegende Paket linux für Ubuntu 22.04 LTS ist als nicht betroffen gekennzeichnet. Das Paket linux-hwe-6.8 ist in derselben Version jedoch anfällig. Administratoren müssen daher den tatsächlich installierten Kernel-Typ und Paket-Zweig prüfen.

Die veröffentlichten relevanten Statusangaben lauten:

Paket	Ubuntu-Version	Status
linux	26.04 LTS, Resolute	Anfällig, Behebung in Arbeit
linux	24.04 LTS, Noble	Anfällig
linux	22.04 LTS, Jammy	Nicht betroffen
linux-hwe-6.8	22.04 LTS, Jammy	Anfällig
linux-hwe-6.17	24.04 LTS, Noble	Anfällig
linux-hwe-7.0	24.04 LTS, Noble	Anfällig
linux-aws	26.04 LTS, Resolute	Anfällig
linux-aws	24.04 LTS, Noble	Anfällig
linux-aws	22.04 LTS, Jammy	Nicht betroffen
linux-aws-6.8	22.04 LTS, Jammy	Anfällig
linux-aws-7.0	26.04 LTS, Resolute	Anfällig
linux-azure	26.04 LTS, Resolute	Anfällig
linux-azure	24.04 LTS, Noble	Anfällig
linux-azure	22.04 LTS, Jammy	Nicht betroffen
linux-azure-6.8	22.04 LTS, Jammy	Anfällig

Mehrere ältere oder abgelöste Zweige sind als nicht betroffen, nicht veröffentlicht, ignoriert oder als End of Life gekennzeichnet. Dazu gehören beispielsweise linux-kvm unter Ubuntu 22.04, 20.04 und 18.04 sowie die AWS-, Azure- und HWE-Zweige 5.15 unter Ubuntu 20.04.

Die verfügbare Ubuntu-Sicherheitsmitteilung enthält keinen Status für ein GCP-spezifisches Paket. Außerdem nennt sie kein Datum für korrigierte Ubuntu-Builds.

Ein Upstream-Patch ist vorhanden, die Behebung durch Ubuntu jedoch noch nicht abgeschlossen

Der anfällige Kernel-Code wurde in Linux 6.10 eingeführt und in die stabilen Zweige 6.1 und 6.6 zurückportiert.

Die Korrektur wurde am 6. August in den Mainline-Kernel 7.2 und den Stable-Kernel 7.1.10 übernommen. Organisationen, die eigene Kernel pflegen, können die Änderung direkt übernehmen, vorbehaltlich ihrer üblichen Test- und Bereitstellungsprozesse.

Die Verfügbarkeit im Upstream bedeutet jedoch nicht, dass jeder Ubuntu-Kernel-Zweig bereits ein korrigiertes Paket erhalten hat. Ubuntu führt weiterhin mehrere Zweige als anfällig, wobei das Ubuntu-26.04-Basispaket linux ausdrücklich als „Behebung in Arbeit“ gekennzeichnet ist.

Weder Ubuntu noch DepthFirst haben eine vorübergehende Gegenmaßnahme veröffentlicht. Es gibt außerdem keine offengelegten Exploit-Signaturen, forensischen Artefakte oder zuverlässigen Indikatoren auf Kernel-Ebene, mit denen Verteidiger versuchte Ausnutzungen erkennen könnten.

KI-gestützte Forschung führte zu einem funktionierenden Kernel-Exploit

DepthFirst zufolge identifizierte das Schwachstellenerkennungsmodell dfs-large1 den Fehler mit Unterstützung einer von Menschen betriebenen Testumgebung. Das Unternehmen nutzte den Exploit, um am 24. Juli einen Platz im Google-kernelCTF zu gewinnen, und meldete das Problem am 5. August an das Kernel-Sicherheitsteam.

Kernel-Entwickler teilten DepthFirst anschließend mit, dass ein OpenAI-Forscher denselben Fehler unabhängig entdeckt hatte. Im CVE-Commit wird Kyle Zeng als Meldender genannt.

Der Vorfall zeigt mehr als eine automatisierte Triage von Fehlern. Der Forschungsprozess führte zu einem funktionierenden Container-Ausbruch gegen Ubuntu 26.04 und umfasste die Entdeckung, die Analyse der Race Condition, die Entwicklung des Exploits und die Validierung an einem praxisnahen Ziel.

Er reiht sich außerdem in weitere Kernel-Schwachstellen ein, die durch KI-gestützte Forschung entdeckt wurden und eine Rechteausweitung bis hin zu Root auf dem Host ermöglichen. Die öffentliche Verfügbarkeit von Exploits ist für ungepatchte Linux-Hosts zu einem wiederkehrenden betrieblichen Problem geworden und nicht mehr nur ein Maß für die theoretische Schwere einer Schwachstelle.

Verteidiger sollten Kernel-Inventarisierung und eine stärkere Isolation priorisieren

Administratoren sollten zunächst jeden Container-Host dem installierten Kernel-Paket und -Zweig zuordnen. Es reicht nicht aus, lediglich zu prüfen, ob ein Rechner Ubuntu 22.04, 24.04 oder 26.04 ausführt, da Basis-, HWE-, AWS- und Azure-Pakete unterschiedliche Statusangaben aufweisen.

Soweit möglich, sollten betroffene eigene Kernel die Korrektur aus dem Upstream erhalten. Ubuntu-verwaltete Systeme sollten korrigierte Distributionspakete installieren, sobald diese verfügbar sind.

Bis dahin sollten Organisationen überprüfen, welche Workloads sich einen Kernel teilen dürfen. DepthFirst empfiehlt eine Isolation auf Basis von MicroVMs, etwa mit Firecracker oder Kata Containers, für nicht vertrauenswürdigen Code. Diese Ansätze stellen Workloads jeweils eigene Kernel bereit und verhindern so, dass ein Container-Kernel-Exploit den primären Host-Kernel direkt kompromittiert.

Die Überwachung sollte sich auf unerwartete Prozesse auf Host-Ebene konzentrieren, die aus Container-Kontexten stammen, auf nicht erklärbare Rechteausweitungen sowie auf unbefugte Änderungen an Host-Dateien oder der Laufzeitkonfiguration. Dabei handelt es sich um verhaltensbasierte Warnsignale und nicht um schwachstellenspezifische Indikatoren.

Das Ausbleiben bestätigter Angriffe oder eines Eintrags im CISA-KEV-Katalog sollte nicht mit einer geringen Ausnutzbarkeit verwechselt werden. Funktionierender Code ist bereits öffentlich verfügbar, und die betroffenen Schnittstellen sind in standardmäßigen Container-Konfigurationen zugänglich.