Linux-Kernel Bad Epoll CVE-2026-46242: Lokaler Nutzer erhält Root auf Kernel 6.4 und neuer
Am 4. Juli 2026 wurde CVE-2026-46242 veröffentlicht, eine Use-after-free-Race-Condition in der epoll-Subsystem des Linux-Kernels. Lokale Nutzer können mit sehr hoher Zuverlässigkeit Root-Rechte auf allen betroffenen Systemen erlangen, Kernel-Neustart erforderlich nach Patch.
Am 4. Juli 2026 wurde die Linux-Kernel-Schwachstelle CVE-2026-46242 öffentlich bekannt, die unter dem Namen Bad Epoll für Aufsehen sorgt. Die Schwachstelle ist eine Kombination aus Race-Condition und Use-after-free in der epoll-Subsystem und betrifft alle Kernel-Versionen ab 6.4. Lokale unprivilegierte Nutzer können mit sehr hoher Zuverlässigkeit Root-Rechte erlangen, auf Linux-Servern ebenso wie auf Desktop-Systemen und Android-Geräten. Ein erster Patch-Versuch war fehlerhaft, ein korrigierter Patch steht inzwischen bereit.
Was ist passiert?
Die Schwachstelle sitzt in der Datei fs/eventpoll.c, dem zentralen Code für das epoll-Event-Notification-Subsystem des Kernels. Unter bestimmten Race-Bedingungen zwischen parallelen epoll-Operationen wird ein bereits freigegebener Speicherbereich erneut verwendet, ein klassischer Use-after-free. Ein lokaler Nutzer kann diese Race-Bedingung gezielt provozieren und dabei eigenen Code in den freigegebenen Speicher schreiben, der anschließend im Kernel-Kontext mit Root-Rechten ausgeführt wird. Sicherheitsforscher berichten von Erfolgsquoten um 99 Prozent, sodass der Bug in der Praxis als deterministisch betrachtet werden kann. Der erste Kernel-Patch war fehlerhaft und löste das Problem nicht zuverlässig, die Korrektur erforderte eine zweite Iteration, die nun in den jeweiligen Distributionen ausgerollt wird.
Wer ist betroffen?
Betroffen sind alle Linux-Systeme mit Kernel 6.4 oder neuer, das schließt aktuelle Ubuntu-Versionen, Debian Trixie, RHEL 9.x, SUSE, Fedora, Arch und Android-Geräte mit aktuellem Generic-Kernel-Image ein. Besonders gefährdet sind Multi-User-Server, CI-Runner, Build-Slaves, Container-Hosts mit erlaubtem Nutzer-Exec und Webhosting-Plattformen, auf denen Kunden-Accounts Code als lokaler Nutzer ausführen können. Nicht betroffen sind Kernel vor 6.4, Embedded-Geräte mit alten LTS-Kernels und Distributionen, die den korrigierten Patch bereits eingespielt haben. Single-User-Workstations sind technisch ebenfalls verwundbar, in der Praxis aber weniger attraktiv für Angreifer, weil das lokale Konto ohnehin mit vollem Zugriff auf den Desktop arbeitet.
Wie kritisch ist das?
Es handelt sich um eine lokale Privilegien-Eskalation, nicht um eine Netzwerk-Lücke. Ein Angreifer benötigt also bereits ein unprivilegiertes Konto oder die Möglichkeit, Code im Kontext eines solchen Kontos auszuführen. In Containern ohne ausreichende Isolation oder mit aktiviertem privileged-Flag kann der Bug zudem als Container-Escape missbraucht werden. Für klassische Server mit wenigen administrativen Konten ist die Bedrohung daher geringer als für Hosting- und CI-Umgebungen, in denen Dutzende oder Hunderte Nutzer aktiv sind. Die sehr hohe Erfolgsquote und die breite Verfügbarkeit eines Proof-of-Concept machen den Bug trotzdem zu einem Pflicht-Patch für jeden KMU-Linux-Server.
Was sollten Admins jetzt tun?
- Kernel-Version ermitteln: Auf allen Servern
uname -rausführen und das Ergebnis dokumentieren. Verwundbar sind alle Kernel 6.4 und neuer, bei denen der Distributions-Patch noch nicht eingespielt wurde. - Distribution-Pakete einspielen: Die jeweils aktuellen Kernel-Pakete über den normalen Update-Kanal einspielen, etwa
apt full-upgradeauf Debian und Ubuntu,dnf update kernelauf RHEL, Fedora und AlmaLinux oderzypper upauf SUSE. Den enthaltenen Kernel erst nach einem kontrollierten Neustart aktivieren. - Live-Patch erwägen: Wo ein Neustart kurzfristig nicht möglich ist, Live-Patch-Dienste wie KernelCare, Ksplice oder Livepatch von Canonical nutzen, die den Patch ohne Reboot in den laufenden Kernel einspielen. Anschließend trotzdem einen Wartungszyklus für den regulären Reboot einplanen.
- Lokale Nutzer prüfen: Liste der lokalen Konten auf allen verwundbaren Servern prüfen, ungewöhnliche oder längst gelöschte Konten deaktivieren und SSH-Key-basierte Authentifizierung als Standard setzen, damit kein Konto ohne private Schlüssel-Datei Root-Zugriff erhalten kann.
- Logs auswerten: In den SSH-, sudo- und Audit-Logs der vergangenen 30 Tage nach ungewöhnlichen sudo-Aufrufen, unbekannten Login-Quellen und plötzlichen Änderungen an
/etc/passwdund/etc/shadowsuchen. - Container-Hosts absichern: Container-Setups mit restriktiven Security-Optiones fahren, insbesondere
no-new-privilegessetzen, dasprivileged-Flag vermeiden und User-Namespaces restriktiv konfigurieren, damit ein lokaler Root-Aufstieg in einem Container nicht sofort den Container-Escape ermöglicht.
Einordnung für Unternehmen
Bad Epoll reiht sich in eine Serie von lokalen Kernel-Eskalationen ein, die in den letzten Monaten Wellen geschlagen haben, von der Copy-Fail-Lücke bis hin zu Container-Escapes über ptrace. Für KMU ist entscheidend, einen verlässlichen Patch- und Reboot-Rhythmus zu etablieren, der auch Kernel-Updates zeitnah aufnimmt. Linux-Server, auf denen mehrere Nutzer arbeiten, brauchen zusätzlich eine klare Aufzeichnung darüber, wer wann welche sudo-Rechte hatte, damit nach einem erfolgreichen Angriff zumindest der Zeitraum eingegrenzt werden kann. Wer heute schon mit automatisierten Kernel-Updates und Live-Patching arbeitet, ist für Bad Epoll gut aufgestellt und kann den Patch im regulären Wartungsfenster einspielen.
Passende Anleitungen auf S-EDV
- DirtyClone: Neue Linux-Kernel-Lücke ermöglicht lokale Root-Eskalation ordnet eine vergleichbare Linux-Kernel-Lücke ein und ergänzt die Härtungs-Empfehlungen.
- CISA KEV: Warum der Known Exploited Vulnerabilities Catalog für Admins Pflicht ist hilft bei der Einordnung, welche Linux-Lücken wirklich sofort gepatcht werden müssen.
- OpenSSL: Neun Schwachstellen im Sicherheitsrelease vom 9. Juni 2026 erinnert an einen weiteren Pflicht-Patch für eine in Linux-Servern verbreitete Bibliothek.
