Linux-Kernel: Öffentliche Exploits für vier Root-Lücken

Für vier Sicherheitslücken im Linux-Kernel stehen seit dem 18. September 2026 funktionsfähige Exploits öffentlich bereit. Jede der vier erlaubt es einem lokalen Benutzer ohne Sonderrechte, sich auf einem ungepatchten System root-Rechte zu verschaffen. Die Fehler selbst sind bereits behoben, die Korrekturen sind in den vergangenen Wochen in die stabilen Kernel-Zweige eingeflossen. Neu und der eigentliche Anlass ist die Veröffentlichung des Angriffscodes: Wer noch einen alten Kernel betreibt, hat ab sofort mit frei verfügbaren, getesteten Werkzeugen zu rechnen.

Dringend ist das vor allem auf Systemen mit mehreren, nicht vertrauenswürdigen Benutzern: Mehrbenutzerserver, Shared Hosting, CI-Runner, Jump-Hosts und Container-Hosts. Entspannter dürfen Betreiber von Einzweckmaschinen sein, auf denen niemand außer dem Administrator eine Shell hat und keine fremden Workloads laufen. Ausdrücklich nicht betroffen ist, wer bereits einen Kernel mit allen vier Korrekturen einspielt hat. Und ebenso ausdrücklich: Dies ist keine Remote-Code-Execution. Ein Angreifer braucht zuerst lokalen Zugang oder einen kompromittierten Dienst, aus dem heraus er Code ausführen kann.

Was ist passiert?

Der Sicherheitsforscher Asim Manizada hat vier Schwachstellen im Netzwerk-Code des Linux-Kernels an das Kernel-Security-Team und die zuständigen Maintainer gemeldet, nach eigenen Angaben Mitte Juli 2026. Nach Ablauf des mit der Verteilerliste linux-distros vereinbarten Embargos veröffentlichte er am 18. September 2026 eine Mitteilung auf der Mailingliste oss-security sowie eine technische Analyse samt lauffähigem Exploit-Code für alle vier Lücken.

Die vier Lücken tragen die Namen DirtyAH6, TUNderflow, PPPoEject und DiagSpill. Alle vier sind Speicherfehler in unterschiedlichen Teilen des Kernel-Netzwerkstacks. Die zugrundeliegenden Programmierfehler sind laut Manizada zwischen 10 und 21 Jahre alt. Die Korrekturen sind als Upstream-Commits öffentlich nachvollziehbar.

Name	CVE	Kernel-Bereich	Lokale Voraussetzung
DirtyAH6	CVE-2026-80844	IPsec AH6 (IPv6/XFRM)	unprivilegierte User-Namespaces oder CAP_NET_ADMIN und CAP_NET_RAW
TUNderflow	CVE-2026-81000	TUN/TAP-Netzwerkgeräte	unprivilegierte User-Namespaces oder CAP_NET_ADMIN
PPPoEject	CVE-2026-68121	PPPoE	unprivilegierte User-Namespaces oder CAP_NET_ADMIN
DiagSpill	CVE-2026-74469	SCTP (sctp_diag)	keine, SCTP und sctp_diag genügen

Technisch handelt es sich um klassische Speicherfehler. Bei DirtyAH6 prüfte die AH6-Verarbeitung das Feld segments_left eines IPv6-Routing-Headers nicht gegen die tatsächliche Anzahl der enthaltenen Adressen, ein präpariertes Rohpaket verschob dadurch einen internen Zeiger weit über den Puffer hinaus. TUNderflow nutzt eine Variable, die gleichzeitig als Reserve und als Größenangabe diente: Ein überdimensionierter Headroom-Wert, durchgereicht über Open vSwitch, ließ die Berechnung unterlaufen. PPPoEject ist ein Use-after-free, weil ein Zeiger in einen Netzwerkpuffer über einen Aufruf hinweg gehalten wurde, der diesen Puffer neu anlegen darf. DiagSpill lässt einen nur 16 Bit breiten Zähler für SCTP-Transporte überlaufen, woraufhin die Diagnose-Ausgabe rund 8 MiB Daten über das Ende ihres Puffers schreibt.

Wer ist betroffen?

Betroffen sind Linux-Systeme, deren Kernel die Korrekturen noch nicht enthält. Die ersten stabilen Upstream-Kernel mit allen vier Fixes sind laut Manizadas Veröffentlichung 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 und 7.2.4.

• Wer eine Distribution einsetzt, sollte diese Zahlen nicht direkt vergleichen. Debian, Ubuntu, Red Hat und SUSE pflegen eigene Versionsnummern und backporten die Korrekturen nach eigenem Zeitplan.
• Der Debian Security Tracker weist zum Abrufzeitpunkt am 19.09.2026 für CVE-2026-68121 und CVE-2026-74469 Korrekturen für Bookworm und Trixie aus, für CVE-2026-80844 eine Korrektur in Bookworm-Security, während CVE-2026-81000 dort zu diesem Zeitpunkt nur in Sid als behoben geführt wird.
• Die ersten drei Lücken setzen voraus, dass ein normaler Benutzer sich Netzwerkrechte verschaffen kann, üblicherweise über unprivilegierte User-Namespaces, die viele Distributionen standardmäßig aktiviert haben. Alternativ genügen CAP_NET_ADMIN beziehungsweise CAP_NET_RAW in einem vom Angreifer kontrollierten Netzwerk-Namespace.
• DiagSpill ist die Ausnahme und braucht weder User-Namespaces noch besondere Capabilities. Es genügt, dass die Module SCTP und sctp_diag verfügbar sind.
• Manizada weist darauf hin, dass AppArmor und SELinux die Exploits in seinen Tests nicht blockiert haben. Ausnahme ist der Ubuntu-spezifische Fall, in dem AppArmor die unprivilegierten User-Namespaces selbst unterbindet.
• Nicht betroffen sind Systeme mit aktuellem Kernel sowie, im praktischen Risiko deutlich entschärft, Einzweckmaschinen ohne fremde lokale Nutzer und ohne Container-Workloads.

Wie kritisch ist das?

Der Angriffspfad ist in allen vier Fällen lokale Rechteausweitung, nicht Remote Code Execution. Ein Angreifer muss bereits auf dem System sein, etwa über ein gestohlenes Benutzerkonto, einen ausgenutzten Webdienst oder einen Build-Job auf einem CI-Runner. Wer keinen solchen Fuß in der Tür hat, kommt über diese Lücken nicht herein. Das relativiert die Dringlichkeit, hebt sie aber nicht auf, denn genau diese zweite Stufe entscheidet darüber, ob aus einem kompromittierten Dienst eine vollständig übernommene Maschine wird.

Zwei der Lücken sind unter engen Bedingungen auch über das Netz erreichbar, allerdings nach Darstellung des Forschers im Wesentlichen als Absturz. DirtyAH6 kann einen Host zum Absturz bringen, der als IPv6-Router oder Gateway arbeitet und einen IPsec Authentication Header im Transportmodus hinzufügt. In seinem eigenen Labor erreichte Manizada damit auch Remote-Root, allerdings nur durch vorheriges gezieltes Formen des Speichers auf dem Ziel. Rein aus der Ferne hält er das für, in seinen Worten, extrem schwierig, schließt es aber nicht aus. DiagSpill kann einen Absturz auslösen, wenn ASCONF beziehungsweise ADD-IP zusammen mit SCTP-AUTH oder net.sctp.addip_noauth_enable=1 aktiv sind. Alle diese Optionen sind standardmäßig deaktiviert. Einen Weg zu Remote-Root sieht er hier ausdrücklich nicht.

Zur aktiven Ausnutzung: Es liegen bislang keine Berichte über Angriffe in freier Wildbahn vor. Keine der vier CVE-IDs steht im Known-Exploited-Vulnerabilities-Katalog der US-Behörde CISA, geprüft am 19.09.2026. Der veröffentlichte Exploit-Code ist auf bestimmte Kernel-Builds zugeschnitten und kann Maschinen zum Absturz bringen, er ist also kein universelles Werkzeug. Für Container-Betreiber ist ein Hinweis dennoch bemerkenswert: Nach Angaben des Forschers können alle vier Fehler den Host-Kernel auch aus einem Container heraus beschädigen, was theoretisch einen Container-Ausbruch ermöglichen würde. Ein entsprechender Exploit wurde nicht gebaut.

Was sollten Admins jetzt tun?

• Inventar und Kernel-Version erfassen. Auf jedem System uname -r ausführen und den Wert gegen das Sicherheitsadvisory der eingesetzten Distribution halten, nicht gegen die Upstream-Zahlen.
• Verfügbare Kernel-Updates prüfen. Auf Debian und Ubuntu apt list --upgradable | grep linux-, auf Red Hat, Rocky, Alma und Fedora dnf updateinfo list security, auf SUSE zypper list-patches --category security.
• Bestätigen, dass das Distributionspaket wirklich alle vier Korrekturen enthält. Einzelne CVEs können zu unterschiedlichen Zeitpunkten gebackportet worden sein, hier lohnt der Blick in das jeweilige Changelog oder in den Security Tracker.
• Patch einspielen und neu starten. Ein neuer Kernel wird erst nach dem Reboot wirksam. Wer den Neustart nicht sofort fahren kann, prüft Livepatching: Ubuntu Livepatch für LTS-Kernel, kpatch bei Red Hat, kGraft beziehungsweise Livepatch bei SUSE. Livepatching deckt nicht zwangsläufig jeden dieser vier Fixes ab, der Patchstand ist im jeweiligen Livepatch-Advisory zu prüfen.
• Priorisieren nach Angriffsfläche: zuerst Mehrbenutzersysteme, Shared Hosting, CI- und Build-Runner sowie Container-Hosts, danach interne Anwendungsserver, zuletzt Einzweckmaschinen ohne fremde lokale Nutzer.
• Als Übergangsmaßnahme unprivilegierte User-Namespaces einschränken, sofern keine Anwendung sie benötigt. Auf Debian und Ubuntu über kernel.unprivileged_userns_clone, allgemein über user.max_user_namespaces. Das schließt den einfachen Weg zu DirtyAH6, TUNderflow und PPPoEject, es stoppt aber weder DiagSpill noch einen Prozess, der bereits CAP_NET_ADMIN besitzt.
• Vorsicht bei dieser Maßnahme: Container-Runtimes im Rootless-Betrieb, Flatpak, Snap, Podman und diverse Sandboxes brauchen User-Namespaces. Vor dem Umstellen in einer Testumgebung prüfen, sonst brechen Dienste weg.
• Nicht benötigte Kernel-Module abschalten oder auf die Blacklist setzen, konkret AH6 und XFRM, TUN und TAP, PPPoE sowie SCTP und sctp_diag. Der Forscher empfiehlt ausdrücklich, das Patchen vorzuziehen, weil es weitere Wege zu denselben Fehlern geben kann.
• SCTP separat betrachten. DiagSpill braucht keine Namespaces, daher ist das Entladen von sctp_diag und SCTP auf Systemen ohne SCTP-Bedarf die wirksamste Sofortmaßnahme gegen genau diese Lücke.
• Logs und Monitoring auswerten. Auffällig sind unerwartete Kernel-Oops, Panics und Modul-Ladevorgänge, außerdem Prozesse normaler Benutzer, die Netzwerk-Namespaces anlegen oder rohe Sockets öffnen.
• EDR- und Audit-Regeln nachschärfen: auditd-Regeln für unshare, clone mit CLONE_NEWUSER und CLONE_NEWNET sowie für setns, ergänzt um Alarme auf neue Prozesse mit UID 0, die von einem unprivilegierten Elternprozess abstammen.
• Nicht auf AppArmor oder SELinux allein verlassen. Nach Testaussage des Forschers blockieren beide die Exploits nicht, mit Ausnahme des Ubuntu-Falls, in dem AppArmor die User-Namespaces selbst einschränkt.
• Vor dem Kernel-Update ein Backup beziehungsweise einen Snapshot anlegen und sicherstellen, dass der vorherige Kernel im Bootmenü noch auswählbar ist. Das ist die Rückfallebene, falls Treiber nach dem Neustart zicken.

Einordnung für Unternehmen

Diese Veröffentlichung reiht sich in eine Serie von Kernel-Lücken zur lokalen Rechteausweitung ein, die 2026 offengelegt wurden. Für die Praxis bedeutet das weniger Aufregung und mehr Routine: Ein funktionierender Kernel-Patchprozess mit planbaren Neustartfenstern ist der eigentliche Hebel. Wer Kernel-Updates nur zweimal im Jahr einspielt, steht bei jeder dieser Veröffentlichungen unter Druck, wer einen monatlichen Rhythmus mit definierten Wartungsfenstern fährt, arbeitet die Sache im normalen Betrieb ab.

Bemerkenswert ist zudem der Weg, auf dem die Lücken gefunden wurden. Manizada gibt an, die vier Fehler mit einem KI-gestützten Verfahren aufgespürt zu haben, das ein Modell des kernelseitigen Speicherverhaltens aufbaut. Der Kernel-Commit zu DirtyAH6 hält das mit einer Assisted-by-Zeile fest, die seinem eigenen Werkzeug zugeschrieben wird. Für Unternehmen heißt das vor allem eines: Die Trefferquote solcher Analysen steigt, und die Zeit zwischen Veröffentlichung einer Lücke und verfügbarem Exploit-Code wird eher kürzer als länger. Wer in der Risikobewertung bisher mit der Annahme gearbeitet hat, lokale Rechteausweitung sei ein theoretisches Problem, sollte diese Annahme überdenken. Für Container-Plattformen und geteilte Build-Infrastruktur gehört der Kernel-Patchstand auf dieselbe Prioritätsstufe wie die Absicherung der Anwendungsschicht.

Passende Anleitungen auf S-EDV

• Linux SCTP CVE-2026-64564: Kernel-Update und Docker-Host-Check: zeigt, wie Sie SCTP-Module auf Docker-Hosts prüfen und abschalten, das gleiche Vorgehen hilft direkt gegen DiagSpill.
• Docker-Container mit AppArmor und SELinux härten: erklärt die Profile im Detail und macht deutlich, wo ihre Grenzen liegen, was im vorliegenden Fall besonders relevant ist.
• Bad-Epoll CVE-2026-46242: lokale Root-Eskalation im Linux-Kernel: ordnet eine frühere Lücke desselben Typs ein und liefert den Vergleichsmaßstab für die Risikobewertung.

Quellen

• oss-security: A quartet of Linux local root vulns (Asim Manizada, 18.09.2026)
• Debian Security Tracker: CVE-2026-80844
• Debian Security Tracker: CVE-2026-74469
• Ubuntu Security: CVE-2026-68121
• The Hacker News: Public Exploits Released for Four Linux Kernel Flaws That Enable Local Root
• CISA Known Exploited Vulnerabilities Catalog (Abruf 19.09.2026)