CVE-2026-80521: Exploit für Container-Escape, Ubuntu ohne Patch
DepthFirst hat Exploit-Code für CVE-2026-80521 veröffentlicht, einen Use-after-free im AF_UNIX-Subsystem des Linux-Kernels. Der Angriff bricht aus Containern aus und liefert Root auf dem Host. Upstream ist der Fehler seit August gefixt, Ubuntu liefert den Patch für 26.04, 24.04 und 22.04 LTS bisher nicht aus.
Für CVE-2026-80521 gibt es funktionierenden Exploit-Code, aber für Ubuntu noch keinen Patch. Die Schwachstelle steckt im Garbage Collector für AF_UNIX-Sockets im Linux-Kernel und erlaubt den Ausbruch aus einem Container mit Root-Rechten auf dem Host. Betroffen sind Ubuntu 26.04, 24.04 und 22.04 LTS, ausdrücklich auch die Kernel-Pakete für AWS-, Azure- und GCP-Workloads. Ubuntus Security Tracker führt das Linux-Paket für 26.04 als verwundbar mit dem Status "work in progress".
Die entscheidende Einschränkung zuerst: Ein Angreifer braucht bereits Code-Ausführung in einem Container auf dem betroffenen Host. Wer ausschließlich eigene Anwendungen in eigenen Containern betreibt und keinen fremden Code ausführt, hat kein akutes Problem und kann das reguläre Wartungsfenster abwarten. Wer dagegen fremde Images, Kundencode, CI-Jobs aus Pull Requests oder Mandanten-Workloads auf gemeinsam genutzten Hosts laufen lässt, sollte heute prüfen und die Angriffsfläche reduzieren. Patchen ist derzeit über den Distributionsweg nicht möglich.
Was ist passiert?
Die Sicherheitsfirma DepthFirst hat am 22. September 2026 ihre Forschung zu CVE-2026-80521 veröffentlicht, inklusive Exploit-Code, der gegen Ubuntu 26.04 zielt. Es handelt sich um einen Use-after-free im Garbage Collector für AF_UNIX-Sockets des Linux-Kernels, bewertet mit CVSS 7.8.
Upstream ist der Fehler längst behoben. Der Kernel-Fix ist am 6. August 2026 eingeflossen und steckt im Mainline-Kernel 7.2 sowie im Stable-Branch 7.1.10. Die Lücke entsteht durch eine Race Condition: Der Garbage Collector kann neue Referenzen sehen, bevor die Daten, die sie tragen, eingereiht wurden. Läuft der Collector genau in diesem Fenster, gibt er einen Teil einer Gruppe verbundener Sockets frei, ohne den zugehörigen Zeiger aus einer persistenten internen Liste zu entfernen. Der nächste Durchlauf folgt diesem Zeiger in bereits freigegebenen Speicher.
Der verwundbare Code kam mit Kernel 6.10 hinein und wurde zusätzlich in die Stable-Branches 6.1 und 6.6 zurückportiert. Die Versionsnummer allein sagt also wenig aus, entscheidend ist das konkrete Kernel-Paket der Distribution.
Wer ist betroffen?
Ubuntu hat den Patch für 26.04, 24.04 und 22.04 LTS bislang nicht ausgeliefert. Für 26.04 weist der Ubuntu Security Tracker das Linux-Paket als verwundbar aus, 24.04 und 22.04 sind über neuere Kernel-Pakete ebenfalls betroffen. Das schließt die spezialisierten Cloud-Kernel für AWS, Azure und GCP ein. Für keine betroffene Release ist bisher ein Fix erschienen, und der Tracker nennt kein Datum.
Erreichbar ist die Lücke aus einem Container heraus, weil AF_UNIX-Sockets für die lokale Kommunikation zwischen Prozessen zuständig und in den Standard-seccomp-Profilen von Docker und Kubernetes per Default erlaubt sind. Der Fehler sitzt im Aufräumen von Dateideskriptoren, die per SCM_RIGHTS-Nachrichten zwischen Prozessen weitergereicht werden. Weil der Exploit den Kernel über ganz normale, Containern erlaubte Systemaufrufe erreicht, umgeht er Namespace-Isolation, cgroup-Limits und seccomp-Filterung.
Nicht betroffen im praktischen Sinne sind Umgebungen ohne nicht vertrauenswürdigen Code auf dem Host. Ein einzelner Anwendungsserver, auf dem nur selbst gebaute Container der eigenen Firma laufen, bietet keinen Startpunkt für diesen Angriff, solange kein Angreifer zuvor Code in einem dieser Container ausführen kann. Ebenfalls außen vor bleiben Workloads in microVM-Isolation, weil dort jeder Workload einen eigenen Kernel nutzt statt den des Hosts zu teilen.
Wie kritisch ist das?
CVSS 7.8 wirkt auf den ersten Blick moderat, weil lokaler Zugriff vorausgesetzt wird. In Container-Umgebungen ist diese Voraussetzung aber genau das, was ein Angreifer nach der ersten erfolgreichen Anwendungsschwachstelle ohnehin hat. Das Ergebnis ist Root auf dem Host und damit Zugriff auf alle weiteren Container desselben Systems.
Die Lücke steht nicht im CISA-KEV-Katalog, und es gibt keine bestätigten Berichte über Angriffe damit. Das ist der einzige entlastende Faktor. Belastend ist, dass öffentlich verfügbarer Exploit-Code die übliche Reihenfolge umdreht: Normalerweise ist zuerst der Patch da und dann der Exploit. Hier ist es umgekehrt, und die Distribution hat keinen Termin genannt. Weder DepthFirst noch Ubuntu haben einen temporären Workaround veröffentlicht.
DepthFirst ordnet die Lage deutlich ein: Die Hürde für Container-Ausbrüche über Kernel-Angriffe sei so stark gefallen, dass man annehmen müsse, Angreifer könnten das nach Belieben. Diese Einschätzung ist die Position der Firma, keine unabhängig bestätigte Lagebewertung einer Behörde.
Was sollten Admins jetzt tun?
- Kernel-Stand erheben: Auf jedem Container-Host
uname -rausführen und die Version gegen den Bereich ab 6.10 sowie die Backports in 6.1 und 6.6 abgleichen. Anschließend den Ubuntu Security Tracker zur eigenen Release prüfen, weil die reine Versionsnummer wegen der Backports nicht ausreicht. - Inventar der Vertrauensstellung anlegen: Auflisten, auf welchen Hosts fremde Images, Kundencode, CI-Runner mit Pull-Request-Jobs oder Mandanten-Workloads laufen. Genau diese Hosts sind die Risikogruppe, alle anderen können warten.
- Angriffsfläche reduzieren statt patchen: Nicht vertrauenswürdige Workloads von gemeinsam genutzten Hosts trennen und auf dedizierte Systeme verschieben, deren Kompromittierung keine anderen Kunden betrifft.
- microVM-Isolation prüfen: DepthFirst empfiehlt für nicht vertrauenswürdige Workloads Firecracker oder Kata Containers, weil dort jeder Workload einen eigenen Kernel bekommt.
- Upstream-Patch bewerten: Organisationen, die eigene Kernel bauen oder pflegen, können den bereits am 6. August 2026 eingeflossenen Upstream-Fix direkt anwenden, statt auf das Distributions-Update zu warten.
- Ubuntu Security Tracker beobachten: Den Eintrag zur eigenen Release regelmäßig prüfen und das Update einspielen, sobald es erscheint. Ein Datum gibt es bisher nicht.
- Container-Einstieg erschweren: Anwendungen in Containern aktuell halten, damit ein Angreifer erst gar nicht die für den Exploit nötige Code-Ausführung erreicht. Die Kernel-Lücke ist der zweite Schritt einer Kette, nicht der erste.
- Monitoring schärfen: Auf ungewöhnliche Prozessaktivität, unerwartete Rechteausweitung und Kernel-Oops-Meldungen im Host-Log achten. Ein fehlgeschlagener Exploit-Versuch hinterlässt häufig Spuren im Kernel-Log.
- Images vor dem Start prüfen: Fremde Images vor dem Einsatz auf bekannte Schwachstellen scannen, damit die erste Stufe der Angriffskette nicht aus dem eigenen Image kommt.
- Rechte im Container senken: Non-Root-User, schreibgeschützte Dateisysteme und minimale Capabilities ändern nichts an der Kernel-Lücke selbst, erschweren aber die vorgelagerten Schritte einer Angriffskette deutlich.
- Notfallplan festlegen: Für die Risikohosts vorab klären, wer im Fall eines bestätigten Ausbruchs entscheidet, ob der Host isoliert und neu aufgesetzt wird. Ein Host-Root-Zugriff lässt sich nicht selektiv bereinigen.
Einordnung für Unternehmen
Die praktische Lehre aus diesem Fall ist unbequem, aber nicht neu: Container sind keine Sicherheitsgrenze gegenüber nicht vertrauenswürdigem Code. Sie trennen Prozesse und Ressourcen sauber voneinander, aber sie teilen sich einen Kernel, und jede ausnutzbare Kernel-Lücke hebelt diese Trennung aus. Für den typischen Mittelständler, der seine eigene Anwendung in eigenen Containern betreibt, ist das ein überschaubares Risiko. Für Hoster, Agenturen mit Kundenumgebungen auf gemeinsamen Maschinen und Betreiber öffentlicher CI-Systeme ist es ein Architekturthema.
Der Fall zeigt außerdem, wie sich die Fundrate verändert. DepthFirst gibt an, die Lücke mit dem eigenen, auf Schwachstellensuche trainierten KI-Modell dfs-large1 zusammen mit einem menschlich gesteuerten Test-Harness gefunden zu haben. Die Firma gewann am 24. Juli 2026 mit dem Exploit einen Slot im Google-kernelCTF und meldete den Fehler am 5. August 2026 an das Kernel-Security-Team. Die Maintainer antworteten, ein Forscher bei OpenAI habe denselben Fehler unabhängig gemeldet; der CVE-Commit nennt den Exploit-Forscher Kyle Zeng als Melder.
Zum Mengengerüst: Laut LinuxCVETracker wurden 2026 knapp 5.700 Linux-Kernel-CVEs veröffentlicht, der höchste Jahreswert bisher. Bereits im April erlaubte eine Lücke im kryptografischen Subsystem des Kernels und im Juli eine offengelegte futex-Lücke einem unprivilegierten Benutzer die Eskalation zu Root auf dem Host. Beide Funde entstanden ebenfalls mit KI-Unterstützung. Wer seine Isolationsstrategie bisher allein auf Namespaces und seccomp gestützt hat, sollte diese Annahme überdenken.
Passende Anleitungen auf S-EDV
- Ghostlock: CVE-2026-43499 im Linux-Kernel zeigt einen früheren Container-Escape mit Root auf dem Host und liefert den Hintergrund zur Serie solcher Kernel-Lücken.
- Docker Compose absichern mit Secrets, Healthchecks und Non-Root erklärt, wie Sie die vorgelagerten Schritte einer Angriffskette im Container selbst erschweren.
- Docker-Images mit Trivy auf Schwachstellen scannen hilft dabei, fremde Images vor dem Start auf bekannte Lücken zu prüfen.
