Ein neuer Fehler im Linux-Kernels erlaubt es einem beliebigen lokalen Nutzer ohne Sonderrechte, sich zu Root hochzuarbeiten. Die Lücke heißt Bad Epoll, ist unter CVE-2026-46242 registriert und betrifft nicht nur Server und Desktops, sondern auch Android-Geräte. Ein Patch existiert bereits, öffentlich funktionierender Exploit-Code ebenfalls. Wer verwundbare Systeme betreibt, sollte jetzt handeln.

Worum es geht

Bad Epoll steckt in der epoll-Funktion des Kernels. Epoll ist der Mechanismus, über den ein einzelnes Programm gleichzeitig tausende Dateien und Netzwerkverbindungen überwachen kann. Praktisch jeder moderne Webserver, viele Datenbanken, Laufzeitumgebungen wie Node.js oder Python-asyncio und auch das Event-System von Android setzen darauf auf. Genau deshalb ist die Lücke so unangenehm: epoll ist eine Kernfunktion, die sich nicht einfach abschalten lässt.

Technisch handelt es sich um eine Use-after-Free-Situation, ausgelöst durch eine Race-Condition. Zwei Kernel-Vorgänge versuchen fast gleichzeitig, dasselbe interne Objekt aufzuräumen. Der eine gibt den Speicher frei, während der andere noch hineinschreibt. Diese winzige Kollision reicht aus, um Kernel-Speicher zu manipulieren und sich anschließend bis zu Root hochzuhangeln.

Der CVSS-Score liegt laut SecurityWeek bei 7.8. Entdeckt und als Exploit ausgearbeitet hat die Lücke Jaeyoung Chung vom Computer Security Lab der Seoul National University. Er reichte den Fund als Zero-Day im Rahmen von Googles Bug-Bounty-Programm kernelCTF ein, wofür eine Prämie von mindestens 71.337 US-Dollar vorgesehen ist.

Warum die Lücke besonders brisant ist

Drei Punkte heben Bad Epoll von vielen anderen Privilege-Escalation-Bugs ab.

Erstens gehört sie zu den wenigen Kernel-Lücken, mit denen sich überhaupt Android rooten lässt. Von rund 130 über kernelCTF ausgenutzten Schwachstellen kommen dafür nur etwa zehn infrage, weil die meisten auf Kernel-Module angewiesen sind, die Android gar nicht lädt.

Zweitens lässt sich der Fehler sogar aus der abgeschotteten Sandbox des Chrome-Renderers heraus auslösen, in der fast alle anderen Kernel-Bugs wirkungslos bleiben. Ein Angreifer könnte also einen Browser-Fehler mit Bad Epoll verketten und so direkt bis in den Kernel vordringen.

Drittens gibt es keinen Notausschalter. Anders als bei verwandten Lücken, die sich durch Entladen des betroffenen Moduls entschärfen lassen, ist epoll fest im Kernel verankert. Die einzige wirksame Abhilfe ist der Patch.

So läuft der Angriff ab

Der öffentlich beschriebene Exploit nutzt vier miteinander verknüpfte epoll-Objekte, organisiert in zwei Paaren. Ein Paar bringt die Race-Condition immer wieder zur Auslösung, das andere dient als Opfer. Werden zwei parallele Schließvorgänge gezielt zur Kollision gebracht, entsteht die Use-after-Free-Situation.

Aus einem winzigen Acht-Byte-Schreibfehler baut der Angreifer schrittweise mehr Kontrolle auf, unter anderem über einen Cross-Cache-Angriff, bis er über die Datei /proc/self/fdinfo beliebige Kernel-Speicherbereiche auslesen kann. Am Ende steht eine manipulierte ROP-Kette, die eine Root-Shell verschafft. Trotz des extrem schmalen Zeitfensters gelingt der Angriff laut Chung in rund 99 Prozent der Fälle auf dem Referenzsystem lts-6.12.67.

Der Name reiht sich bewusst in die „Bad“-Serie android-tauglicher Kernel-Lücken ein, zu der bereits Bad Binder, Bad IO_uring und Bad Spin gehören.

Der Bug, den die KI übersah

Bemerkenswert ist die Vorgeschichte. Ein einziger Commit aus dem Jahr 2023 baute gleich zwei getrennte Race-Conditions in die rund 2.500 Zeilen epoll-Code ein. Beide erwiesen sich als kritisch.

Die erste dieser beiden Lücken fand Anthropics KI-Modell Mythos und meldete sie als CVE-2026-43074. Das ist für sich genommen ein starkes Ergebnis, denn Race-Conditions gelten als besonders schwer aufzuspüren. Die zweite, subtilere Lücke, eben Bad Epoll, übersah die KI jedoch.

Chung nennt zwei plausible Gründe. Zum einen ist das Zeitfenster der Race-Condition nur etwa sechs Instruktionen breit, sodass sich der genaue Ablauf selbst beim Blick auf den Quellcode kaum vorstellen lässt. Zum anderen liefert die Lücke kaum Laufzeit-Hinweise: Nachdem die erste Schwachstelle behoben war, löste Bad Epoll den Speicherfehler-Detektor KASAN meist nicht mehr aus. Ohne dieses Signal fehlte der KI vermutlich die nötige Sicherheit, den Fund als echten Bug zu melden.

Auch für die Kernel-Maintainer war die Lücke keine leichte Aufgabe. Ihr erster Patch-Versuch reichte nicht aus, ein wirklich funktionierender Fix folgte erst rund zwei Monate nach der Erstmeldung. Für einen Kernel, der Sicherheitsprobleme sonst mit Nachdruck angeht, ist das ein langer Zeitraum.