Linux-Kernel-Lücken: Exploits für vier Root-Schwachstellen sind jetzt öffentlich

Am 18. September 2026 hat der Sicherheitsforscher Asim Manizada funktionierenden Exploit-Code für vier Linux-Kernel-Lücken veröffentlicht. Jede einzelne verschafft einem lokalen Benutzer Root-Rechte. Die gute Nachricht steht gleich am Anfang: Alle vier sind gepatcht. Die schlechte: Der Weg dorthin ist jetzt öffentlich dokumentiert.

Die vier Lücken im Überblick

Manizada hat ihnen Namen gegeben, wie es in dieser Disziplin üblich geworden ist:

Newsletter

Klartext ins Postfach

KI, Security & Crypto – die wichtigsten Analysen, kein Spam. Jederzeit abbestellbar.

E-Mail-Adresse *

Vorname

Nachname

• DirtyAH6 (CVE-2026-80844) – im IPsec-Code für den IPv6-Authentication-Header.
• TUNderflow (CVE-2026-81000) – in den virtuellen Netzwerkgeräten TUN und TAP.
• PPPoEject (CVE-2026-68121) – in der Verarbeitung von PPP over Ethernet.
• DiagSpill (CVE-2026-74469) – im Diagnose-Code des SCTP-Protokolls. Der NVD-Eintrag führt dafür 8,8 Punkte, allerdings als Bewertung des kernel.org-CNA; eine eigene NVD-Analyse liegt noch nicht vor.

Alle vier sind Speicherfehler im Netzwerk-Teil des Kernels. Die zugrunde liegenden Programmierfehler sind zwischen zehn und 21 Jahre alt. Gemeldet hat Manizada sie Mitte Juli an security@kernel.org; die Veröffentlichung am 18. September war mit den Linux-Distributionen abgestimmt, damit die Korrekturen zuerst ausgeliefert werden konnten.

Wer tatsächlich betroffen ist

Hier lohnt es sich, genauer hinzusehen, denn die Voraussetzungen unterscheiden sich deutlich – und werden in Kurzmeldungen gern verkürzt.

Für DirtyAH6, TUNderflow und PPPoEject braucht ein Angreifer bestimmte Netzwerk-Berechtigungen. In der Praxis holt er sie sich über unprivilegierte User-Namespaces, die viele Distributionen standardmäßig aktiviert haben. Manizada weist aber ausdrücklich darauf hin, dass es auf die Berechtigungen selbst ankommt: Ein Prozess oder Container, der ohnehin CAP_NET_ADMIN besitzt – bei DirtyAH6 zusätzlich CAP_NET_RAW –, erreicht diese Fehler auch ohne neue Namespaces und kann damit den Kernel des Hosts beschädigen.

DiagSpill ist der Ausreißer. Diese Lücke braucht keinerlei Sonderrechte und keine User-Namespaces. Es genügt, dass auf dem System SCTP samt sctp_diag verfügbar ist.

Zwei der Fehler lassen sich unter sehr engen Bedingungen auch über das Netz auslösen, dann aber im Wesentlichen nur zum Absturz. Und „eng” ist hier wörtlich gemeint: DirtyAH6 verlangt ein System, das als IPv6-Router arbeitet und AH im Transport-Modus einsetzt; DiagSpill braucht eingeschaltetes ASCONF/ADD-IP zusammen mit SCTP-AUTH oder net.sctp.addip_noauth_enable=1. All das ist standardmäßig aus. Remote-Root hat Manizada einzig mit DirtyAH6 erreicht, und das im eigenen Labor mit vorbereitetem Speicherzustand. Rein aus der Ferne hält er das sinngemäß für extrem schwierig („looks extremely difficult”), ohne es völlig auszuschließen. Für DiagSpill sieht er gar keinen Weg zu Remote-Root.

AppArmor und SELinux haben die Exploits in seinen Tests übrigens nicht aufgehalten – abgesehen davon, dass Ubuntu über AppArmor unprivilegierte User-Namespaces blockiert.

Was das für dich bedeutet

Lokale Rechteausweitung hat in der öffentlichen Wahrnehmung ein Imageproblem. „Der Angreifer muss ja schon drauf sein” – dieser Satz fällt in Diskussionen regelmäßig, und er ist der Grund, warum solche Lücken in Patch-Zyklen nach hinten rutschen.

Aus der Praxis heraus halte ich das für einen Denkfehler. Jeder ernsthafte Angriff besteht aus zwei Hälften: hineinkommen und hochkommen. Der erste Teil gelingt über Phishing, ein geleaktes Passwort, eine Web-Anwendung oder einen kompromittierten Dienstaccount – und er gelingt häufiger, als uns lieb ist. Was danach passiert, entscheidet, ob daraus ein Vorfall oder eine Katastrophe wird. Genau an dieser Stelle sitzt Local Privilege Escalation.

Dass das keine graue Theorie ist, zeigt das Timing: Einen Tag nach dieser Veröffentlichung, am 19. September, hat die US-Behörde CISA drei andere Kernel-Lücken als aktiv ausgenutzt in ihren Katalog aufgenommen. Die vier hier besprochenen sind davon nicht betroffen – aber die Angriffsklasse ist offensichtlich in Gebrauch.

Besonders unangenehm wird es bei geteilten Systemen. Ein Webhosting-Server mit vielen Kunden, ein Build-Server, auf dem fremder Code läuft, ein Container-Host: Überall dort ist der „lokale Benutzer” kein hypothetisches Konstrukt, sondern Teil des Betriebsmodells. Der Hinweis auf die Capabilities ist deshalb der praktisch wichtigste Satz des gesamten Berichts – wer Containern großzügig Netzwerkrechte gibt, sollte diese Zeile zweimal lesen.

Und ein Punkt, der über diesen Fall hinausweist: Manizada hat die vier Lücken nach eigener Aussage mit KI-Unterstützung gefunden. Im Kernel-Commit zu DirtyAH6 steht dafür eine eigene „Assisted-by”-Zeile, die sein Werkzeug nennt. Das ist keine Randnotiz. Die Geschwindigkeit, mit der solche Fehler künftig gefunden werden, verschiebt sich gerade – und zwar für beide Seiten. Wer Patch-Zyklen in Quartalen denkt, arbeitet mit einem Zeitmaß, das aus einer anderen Epoche stammt.

Konkrete Schritte

1. Prüfe zuerst, was wirklich läuft. uname -r zeigt den aktiven Kernel – nicht das installierte Paket. Ein Kernel-Update ohne Neustart ist folgenlos, und genau dieser Schritt fehlt in der Praxis am häufigsten.
2. Capabilities in Containern durchsehen. CAP_NET_ADMIN wird oft vergeben, weil „sonst etwas nicht funktioniert”. Diese Lücken zeigen, was daran hängt – und dieser Punkt wird von keiner Kernel-Version repariert.
3. Kernel aktualisieren. Die ersten Upstream-Versionen mit allen vier Korrekturen sind laut Manizada 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 und 7.2.4. Achtung bei 7.1.y: Dieser Zweig bekommt für TUNderflow keine Korrektur mehr, hier führt der Weg auf 7.2.4.
4. Nicht die Versionsnummern vergleichen, sondern das Advisory lesen. Debian, Ubuntu, Red Hat und SUSE pflegen eigene Versionsstände und portieren Korrekturen zurück. Eine niedrigere Nummer heißt dort nicht automatisch „ungepatcht” – und eine höhere nicht automatisch „sicher”.
5. Wenn du nicht sofort patchen kannst: Unprivilegierte User-Namespaces abschalten nimmt den ersten drei Lücken den gewöhnlichen Benutzerpfad. Gegen DiagSpill hilft das nicht, und gegen einen Container mit entsprechenden Capabilities ebenso wenig.
6. Ungenutzte Funktionen abschalten. Manizada nennt AH6, TUN, PPPoE und SCTP/sctp_diag. Was nicht verfügbar ist, lässt sich nicht angreifen. Er selbst empfiehlt das allerdings nur als Notlösung – es könnten andere Wege zu denselben Fehlern existieren.

Wer einen NAS oder Heimserver mit Linux betreibt, findet in meinem Ratgeber zu NAS und Heimservern für Selfhosting die passende Grundausstattung – inklusive der Frage, welche Geräte überhaupt noch Kernel-Updates bekommen. Dass SCTP im Kernel regelmäßig für Ärger sorgt, ist übrigens kein Zufall: Erst im August ging es hier um SCTPhantom, eine andere SCTP-Lücke mit Root-Rechten.

Fazit

Es gibt keinen Grund zur Aufregung: Die Korrekturen sind seit Wochen verfügbar, es gibt keine Berichte über Angriffe auf diese vier Lücken, und die Exploits sind auf bestimmte Kernel-Builds zugeschnitten. Es gibt aber einen guten Grund, die Kernel-Version der eigenen Server heute nachzusehen statt beim nächsten Wartungsfenster.

Der Unterschied zwischen einer gepatchten und einer ungepatchten Maschine bestand bis vorgestern darin, dass niemand den Exploit hatte. Diesen Unterschied gibt es jetzt nicht mehr.

Quellen

• Asim Manizada: A quartet of Linux local root vulns (18.09.2026)
• The Hacker News: Public Exploits Released for Four Linux Kernel Flaws (18.09.2026)
• NVD: CVE-2026-74469 (DiagSpill)
• NVD: CVE-2026-80844 (DirtyAH6)