Zum Inhalt springen

Ein falsches Zeichen, volle Root-Rechte: Öffentliche Exploits für Linux-Kernel-Lücke CVE-2026-23111

Für eine gefährliche Lücke im Linux-Kernel kursieren inzwischen mehrere funktionierende Exploits öffentlich. Die Schwachstelle mit der Kennung CVE-2026-23111 erlaubt es einem lokalen Angreifer ohne besondere Rechte, sich vollständige Root-Rechte auf dem System zu verschaffen. Der Patch existiert seit Anfang Februar 2026, doch viele Produktivsysteme haben ihn nie eingespielt. Mit der Veröffentlichung von fertigem Exploit-Code ist die Schonfrist vorbei.

Worum es geht

Die Lücke steckt im nf_tables-Subsystem des Kernels, der Komponente, die für die Paketfilterung zuständig ist und unter anderem die moderne Firewall unter Linux antreibt. Es handelt sich um einen Use-after-free-Fehler, bei dem der Kernel auf einen Speicherbereich zugreift, der bereits freigegeben wurde. Auslöser war ein einziges falsch gesetztes Zeichen: ein invertierter genmask-Check in der Funktion nft_map_catchall_activate(), der beim Abbruch einer Transaktion zu fehlerhaftem Verhalten führte. Der offizielle Fix bestand darin, genau dieses eine Zeichen zu entfernen, ein einzelnes Ausrufezeichen im Quellcode.

Ubuntu bewertet die Schwachstelle mit einem CVSS-Score von 7.8, was als hoch gilt. Einen Angriff aus der Ferne ermöglicht die Lücke für sich genommen nicht. Ein Angreifer braucht also zunächst irgendeinen Zugang zum System, etwa ein kompromittiertes Nutzerkonto oder einen Prozess mit geringen Rechten.

Warum das so viele Systeme betrifft

Die Lücke lässt sich ausnutzen, wenn zwei Voraussetzungen zusammenkommen: aktives nf_tables und aktivierte unprivilegierte User Namespaces. Letzteres ist eine Linux-Funktion, die einem normalen Konto erlaubt, innerhalb einer abgeschotteten Sandbox wie root zu agieren und dabei Kernel-Code zu erreichen, der sonst gesperrt wäre. Beide Funktionen sind auf den meisten Desktop-Installationen und vielen Server-Builds standardmäßig aktiv. Da der Fehler im Mainline-Kernel steckt, ist grundsätzlich jede Distribution betroffen, die einen verwundbaren Kernel mit beiden Funktionen ausgeliefert hat, sofern nicht eigene Härtungsmaßnahmen oder Namespace-Beschränkungen den Weg blockieren.

Besonders heikel wird es in Container-Umgebungen. Auf einem gemeinsam genutzten Host mit ungepatchtem Kernel lässt sich die Lücke für einen Container-Ausbruch nutzen. Ein bösartiger oder kompromittierter Container kann seine Isolation durchbrechen und den Host-Kernel mit Root-Rechten erreichen. Docker- und LXC-Workloads sind betroffen, auch Proxmox-Setups. Ein einziger verwundbarer Host gefährdet damit sämtliche Workloads, die auf ihm laufen. Vollständige virtuelle Maschinen bieten hier deutlich stärkere Isolation als unprivilegierte Container.

Die Zeitleiste

Der Patch wurde am 5. Februar 2026 verteilt. Danach vergingen rund vier Monate, bis öffentlicher Exploit-Code auftauchte. FuzzingLabs reproduzierte den Fehler im Vorfeld der Pwn2Own Berlin 2026 auf RHEL 10 und veröffentlichte am 16. April eine eigene, auf anderem Weg entwickelte Root-Ausnutzung. Am 8. Juni folgte Exodus Intelligence mit einer ausführlichen technischen Beschreibung samt funktionierendem Exploit. Die Technik ist damit über Debian, Ubuntu und Red Hat hinweg dokumentiert.

Dieses Muster ist das eigentliche Problem. Zwischen verfügbarem Patch und öffentlichem Exploit lag ein Zeitfenster von vier Monaten, in dem viele Betreiber nicht aktualisiert haben. Kernel-Updates werden gern aufgeschoben, weil sie einen Neustart erfordern und das geplante Wartungsfenster sich immer wieder verschiebt. Mit einem waffenfähigen Exploit in Umlauf ist dieses Aufschieben jetzt ein konkretes Risiko.

Betroffen sind unter anderem die folgenden Versionen, für die Patches bereitstehen:

  • Ubuntu 22.04 LTS (Jammy), 24.04 LTS (Noble) und 25.10
  • Debian 12 (Bookworm) und Debian 13 (Trixie)
  • Debian 11 (Bullseye) LTS über einen Kernel-6.1-Backport
  • Red Hat und weitere Distributionen mit entsprechenden Kernel-Updates

Handlungsempfehlungen
  • Aktualisiert den Kernel auf eine gepatchte Version und startet das System anschließend neu.
  • Prüft gezielt eure Container-Hosts.
  • Falls ein sofortiges Update nicht möglich ist, prüft als Übergangsmaßnahme, ob sich unprivilegierte User Namespaces in eurer Umgebung deaktivieren lassen.
  • Behandelt Systeme, auf denen zwischen Februar und heute nicht vertrauenswürdige lokale Nutzer Zugriff hatten, als potenziell kompromittiert und prüft sie entsprechend.
  • Nehmt Kernel-Patches fest in euren regulären Wartungszyklus auf, statt sie bis zum nächsten Vorfall aufzuschieben.