Bad Epoll (CVE-2026-46242): die Root-Lücke im Linux-Kernel und was sie für Ihre Server bedeutet

Eine neu offengelegte Linux-Kernel-Lücke namens Bad Epoll (CVE-2026-46242) erlaubt es jedem gewöhnlichen Nutzer auf einem Rechner, sich zu vollständigen Root-Rechten zu erheben, und betrifft Linux-Server, Desktops sowie Android-Geräte mit Kernel 6.4 oder neuer. Sie wurde am 3. Juli 2026 veröffentlicht, nachdem der Forscher Jaeyoung Chung einen funktionierenden Exploit beim kernelCTF-Programm von Google eingereicht hatte. Ein Fix ist bereits im Mainline-Kernel enthalten, doch die meisten Distributionen müssen noch einen Backport ausliefern. Die praktische Aufgabe besteht daher jetzt darin, Ihre Kernel-Version zu prüfen und das Sicherheitsupdate Ihrer Distribution einzuspielen, sobald es verfügbar ist.

Eine gute Nachricht vorweg: Zum Zeitpunkt dieses Textes steht der Fehler nicht im Katalog bekannter ausgenutzter Schwachstellen der CISA, und der einzige funktionierende Exploit ist der Proof of Concept aus dem Wettbewerb. Das verschafft Ihnen ein Zeitfenster, um zu patchen, bevor der Fehler in echten Angriffsketten auftaucht.

Was ist Bad Epoll und warum verschafft es Root-Rechte?

Bad Epoll ist ein Use-after-free durch eine Race-Condition im epoll-Subsystem des Kernels – dem Mechanismus, mit dem Linux gleichzeitig eine große Zahl von Dateien und Netzwerk-Sockets überwacht. Zwei Teile des Kernels versuchen zur selben Zeit, dasselbe interne Objekt aufzuräumen: Ein Thread gibt den Speicher frei, während ein anderer noch hineinschreibt. Diese Überschneidung erlaubt es einem Angreifer, Kernel-Speicher gezielt zu beschädigen und die Anmeldedaten des eigenen Prozesses so zu überschreiben, bis der Kernel ihn als Root behandelt.

Bemerkenswert an der Lücke ist, wie schmal die Gelegenheit ist. Das ausnutzbare Zeitfenster der Race-Condition ist nur etwa sechs Maschinenbefehle breit – eine so winzige Zeitspanne, dass sie selbst dann schwer zu treffen ist, wenn man den verwundbaren Code lesen kann. Diese Schwierigkeit ist der Grund, warum sie über zwei Jahre lang niemandem auffiel, und auch, warum ein zuverlässiger Exploit beeindruckend genug ist, um eine kernelCTF-Auszahlung zu verdienen. Sicher macht Sie das jedoch nicht: Sobald jemand den Exploit schreibt, ist das Sechs-Befehle-Fenster nicht länger Ihr Schutz.

Welche Kernel-Versionen sind betroffen?

Der Fehler wurde 2023 durch eine Änderung am epoll-Code eingeführt und mit Linux 6.4 ausgeliefert. Alles von 6.4 bis zur aktuellen Reihe ohne den Fix ist verwundbar; ältere Kernel auf Basis der 6.1-Reihe enthielten den fehlerhaften Code nie und sind nicht betroffen. Der Fix ist der Mainline-Commit a6dc643c6931, der im April 2026 landete, und jede Distribution backportet ihn nach eigenem Zeitplan.

Kernel-Reihe	Betroffen?	Was zu tun ist
6.1 LTS und älter	Nein	Fehler ist älter als diese; keine Maßnahme für diese CVE
6.4 – aktuell (ungepatcht)	Ja	Auf den gepatchten Build Ihrer Distribution aktualisieren, dann neu starten
Jeder Build mit Commit a6dc643c6931	Nein	Bereits behoben; bestätigen und weitermachen
Android auf 6.4+-Kernel	Ja	Auf das Sicherheitsupdate von Gerät/Hersteller warten

Beachten Sie, dass Android betroffen ist, wo das Gerät einen Kernel 6.4 oder neuer ausliefert; Hardware, die noch auf 6.1 läuft, etwa manche bestehende Smartphones, ist nicht betroffen. Auf Servern folgt das Risiko dem Kernel, nicht dem Namen der Distribution – eine „stabile" LTS-Distribution kann also weiterhin einen betroffenen 6.x-Kernel ausführen.

So prüfen und patchen Sie Ihre eigenen Server

Lesen Sie zunächst die laufende Kernel-Version aus und vergleichen Sie sie mit dem Sicherheitshinweis Ihrer Distribution. Auf jedem Linux-System:

uname -r        # z. B. 6.8.0-40-generic — 6.4+ bedeutet: auf den Patch prüfen
apt list --upgradable 2>/dev/null | grep -i linux   # Debian/Ubuntu
dnf updateinfo list security | grep -i kernel        # Fedora/RHEL-Familie

Spielen Sie anschließend das Sicherheitsupdate ein und starten Sie in den neuen Kernel neu. Ein gepatchtes Kernel-Paket bewirkt nichts, bis Sie tatsächlich darauf neu starten – genau der Schritt, den man gerne überspringt. Wenn Sie sich nicht sofort eine Ausfallzeit leisten können, kann ein Live-Patching-Dienst (kernel livepatch unter Ubuntu, kpatch unter RHEL) die Lücke auf unterstützten Kerneln ohne Neustart schließen und Ihnen bis zu einem Wartungsfenster Zeit verschaffen. Behalten Sie den Sicherheitskanal Ihrer Distribution im Auge – Ubuntu USNs, den Debian Security Tracker oder den Advisory-Feed Ihres Herstellers – und achten Sie auf den Eintrag zu CVE-2026-46242, denn der Mainline-Fix und der paketierte Backport erscheinen an unterschiedlichen Tagen.

Warum ein „nur lokaler" Fehler auch für einen einzelnen VPS zählt

Es ist verlockend, einen lokalen Fehler zur Rechteausweitung achselzuckend abzutun: Ein Angreifer muss bereits auf dem Rechner sein, wenn also niemand eine Shell hat, gibt es nichts zu eskalieren. In der Praxis hält diese Logik nicht stand. Lokaler Root-Zugriff ist die zweite Stufe der meisten echten Einbrüche. Eine Web-App mit einer Remote-Code-Execution-Lücke, ein geleakter Deploy-Schlüssel, eine vergiftete Abhängigkeit oder ein kompromittierter Container – sie alle verschaffen einem Angreifer irgendeine Codeausführung als unprivilegierter Nutzer. Bad Epoll ist das, was aus diesem Standfuß volle Kontrolle über den Host macht, einschließlich jeder anderen App und Datenbank auf demselben System.

Genau diese Form von Risiko besteht auf einem selbst verwalteten VPS, wo sich Ihre App, Ihre Datenbank und Ihre Steuerungsebene meist einen Kernel teilen. Wenn Sie Ihren eigenen Server betreiben, gehört dieser Fehler auf dieselbe Härtungs-Checkliste wie SSH-Schlüssel und eine Firewall – die Grundlagen, die wir in unserer Anleitung zum Self-Hosting von Apps auf einem VPS durchgehen. Er erinnert außerdem daran, dass Perimeterschutz allein nicht genügt; mehrschichtige Kontrollen wie das Zero-Trust-Modell gehen davon aus, dass ein Einbruch passieren wird, und begrenzen, was ein einzelnes kompromittiertes Konto erreichen kann.

Wird Bad Epoll in freier Wildbahn ausgenutzt?

Noch nicht. Es gibt keine Anzeichen für einen Einsatz in der Praxis, die Schwachstelle fehlt in der KEV-Liste der CISA, und der einzige öffentliche Exploit ist die kernelCTF-Einreichung. Doch „noch keine Ausnutzung" ist ein Zeitplan, kein Urteil. Öffentliche Kernel-LPEs werden regelmäßig zu Waffen gemacht, sobald Forscher oder Angreifer die Technik nachbauen, und die Details liegen nun offen. Die sichere Annahme ist, dass ein funktionierender Exploit in Umlauf kommen wird – behandeln Sie den Patch daher als zeitkritisch und nicht als optional. Dieses Muster – ein schnell voranschreitender Fehler, gegen den Verteidiger anrennen müssen – wird zur Norm, während Angreifer immer mehr der Arbeit automatisieren, ein Trend, den wir in KI-Agenten-Sicherheit und die Prompt-Injection-Krise behandelt haben.

Häufig gestellte Fragen

Muss ich nach dem Patchen von Bad Epoll neu starten?

Ja, es sei denn, Sie nutzen Live-Kernel-Patching. Das Installieren des aktualisierten Kernel-Pakets bereitet den Fix vor, aber der verwundbare Code läuft weiter, bis Sie in den neuen Kernel booten. Livepatch (Ubuntu) oder kpatch (RHEL) können den Fix auf unterstützten Versionen auf einen laufenden Kernel anwenden, falls Sie nicht sofort neu starten können.

Ist mein Server betroffen, wenn er eine LTS-Distribution ausführt?

Möglicherweise. Entscheidend ist die Kernel-Version, nicht das Marketing der Distribution. Eine LTS-Version kann trotzdem einen Kernel 6.4 oder neuer ausliefern, was genau der betroffene Bereich ist. Führen Sie uname -r aus und prüfen Sie den Sicherheitshinweis Ihrer Distribution zu CVE-2026-46242.

Sind Android-Smartphones gefährdet?

Nur solche mit einem Kernel 6.4 oder neuer. Geräte, die noch auf 6.1-basierten Kerneln laufen, darunter einige aktuelle Smartphones, sind nicht betroffen. Wo ein Gerät im betroffenen Bereich liegt, warten Sie auf das Sicherheitsupdate des Herstellers und installieren Sie es.

Wie schwerwiegend ist das im Vergleich zu einem Remote-Exploit?

Für sich genommen setzt ein lokaler Fehler voraus, dass ein Angreifer bereits einen Standfuß hat, weshalb er unter einem Remote-Code-Execution-Fehler rangiert. In der Praxis ist er der übliche nächste Schritt nach einem ersten Einbruch – deshalb sind lokale Root-Fehler begehrt und deshalb zählt zügiges Patchen trotzdem.

Quellen

• The Hacker News — New "Bad Epoll" Linux Kernel Flaw Lets Unprivileged Users Gain Root: Primärberichterstattung zu CVE-2026-46242, der epoll-Use-after-free-Ursache, dem etwa sechs Befehle breiten Race-Fenster, den betroffenen 6.4+-Kerneln, dem Fix-Commit a6dc643c6931, der Entdeckung durch Jaeyoung Chung über Google kernelCTF und dem fehlenden Einsatz in freier Wildbahn.
• CISA Known Exploited Vulnerabilities Catalog: Referenz, um zu bestätigen, ob CVE-2026-46242 als aktiv ausgenutzte Schwachstelle aufgenommen wurde.
• bad-epoll Proof-of-Concept-Repository: der öffentliche kernelCTF-Exploit-Code, der die Rechteausweitung demonstriert.