Bad Epoll (CVE-2026-46242): Ein Use-after-Free in epoll macht aus jedem lokalen Nutzer Root — auf Linux und Android

TL;DR — 90 Sekunden

Betroffen?

Linux-Kernel ab v6.4 (Commit 58c9b016e128) bis zum Fix, inklusive rückportierter 5.15.209–5.16- und 6.1.175–6.2-Zweige. Konkret u. a.: Debian trixie vor 6.12.95-1 (bookworm/bullseye nicht betroffen), Ubuntu 24.04/25.10/26.04 LTS (22.04 und älter nicht betroffen), CloudLinux/AlmaLinux 9 und 10. Android-Geräte je nach Kernel-Branch potenziell betroffen.

Risiko?

CVSS 3.1: 7.8 (Hoch) — AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Use-after-Free (CWE-416) in ep_remove(), auslösbar durch jeden lokal angemeldeten, unprivilegierten Nutzer — Ergebnis: Root-Rechte.

Sofortmaßnahme?

Kernel-Update auf eine gepatchte Version einspielen (Debian-Security-Suite, Ubuntu-Kernel-Update, RHEL/CloudLinux-Kernel-Update bzw. Livepatch, sobald verfügbar). Eine Konfigurationsabschaltung von epoll existiert nicht — der Patch ist die einzige echte Abhilfe.

Empfehlung?

Bei Multi-Tenant-Hosts, gemeinsam genutzten CI-Runnern, Container-Hosts mit nicht vertrauenswürdigen lokalen Workloads oder K8s/K3s-Nodes: heute patchen, nicht im nächsten Wartungsfenster — ein zuverlässiger öffentlicher Exploit (~99%) macht das dringlich.

Kritikalität?

hoch — lokale Root-Eskalation, öffentlicher hochzuverlässiger Exploit, breite Gerätereichweite (Linux-Server, -Desktops, Android), aber bislang keine bestätigte Ausnutzung in freier Wildbahn und keine CISA-KEV-Aufnahme.

Was ist das Problem?

Der Fehler liegt in fs/eventpoll.c, dem Kernel-Code hinter der epoll-API — dem Event-Notification-Mechanismus, auf dem praktisch jeder moderne Linux-Netzwerkserver aufsetzt (nginx, Caddy, FrankenPHP, Node.js, und indirekt auch PHP-FPM- und TYPO3-Deployments). In ep_remove() wird file->f_ep unter Schutz von file->f_lock auf NULL gesetzt, der Code verwendet das file-Objekt danach aber noch innerhalb derselben kritischen Sektion weiter. Genau in diesem Fenster kann ein paralleler __fput()-Aufruf — ausgelöst durch das Schließen des letzten Dateideskriptors auf ein Objekt — den zugrunde liegenden Speicher bereits freigeben. Der ep_remove()-Pfad greift dann auf bereits freigegebenen Speicher zu: ein klassisches Use-after-Free.

Praktisch ausnutzbar wird das über sogenannte „epoll-watches-epoll“-Konstruktionen — verschachtelte epoll-Instanzen, die sich gegenseitig beobachten — kombiniert mit gezieltem Timing beim Schließen von Deskriptoren. Laut den bislang veröffentlichten technischen Analysen kann ein Angreifer damit ein kmem_cache_free() gegen den falschen Slab-Cache provozieren und so Speicherkorruption mit Kontrolle über die Zielstruktur erreichen. Der Sicherheitsforscher Jaeyoung Chung demonstrierte in seinem öffentlichen Proof-of-Concept (kernelCTF-Einreichung), dass sich daraus zuverlässig — nach eigenen Angaben in rund 99% der Versuche auf einem 6.12er-Kernel — volle Root-Rechte gewinnen lassen, ausgehend von einem gewöhnlichen, unprivilegierten lokalen Account.

Der fehlerauslösende Commit (58c9b016e128) landete bereits im April 2023 in Linux v6.4 — die Lücke existiert also seit gut drei Jahren im Mainline-Kernel, bevor sie öffentlich dokumentiert wurde. Der Fix (a6dc643c6931) pinnt die Datei-Referenz über epi_fget() und einen __free(fput)-Guard, bevor auf file->f_lock zugegriffen wird, und ist mit Linux 7.1-rc1 ins Mainline gelandet.

Wer ist betroffen?

Nach NVD-Angaben betrifft CVE-2026-46242 mehrere Versionsbänder: 5.15.209–5.16, 6.1.175–6.2, 6.4–6.18.32 sowie 6.19–7.0.9 — im Kern also jeden Kernel ab v6.4, der den fehlerauslösenden Commit enthält, plus Rückportierungen in ältere LTS-Zweige. Die konkrete Betroffenheit hängt stark vom jeweiligen Distributions-Kernel ab — pauschale „v6.4+“-Aussagen greifen zu kurz, wie die folgende, gegen Debian- und Ubuntu-Security-Tracker geprüfte Übersicht zeigt:

Wichtig: Diese Tabelle spiegelt den Stand der von uns geprüften Quellen (NVD, Red Hat CVE-Advisory, Debian Security Tracker, Ubuntu CVE-Tracker, TuxCare) zum Zeitpunkt dieses Beitrags wider. Prüfen Sie den aktuellen Patch-Status Ihrer konkreten Distribution und Kernel-Variante selbst, bevor Sie eine Risikoeinschätzung treffen — insbesondere bei CloudLinux/AlmaLinux 9 und bei Android-Geräteflotten, wo die Quellenlage zum jetzigen Zeitpunkt weniger eindeutig ist.

Auswirkungen

Die unmittelbare Auswirkung ist eine lokale Privilege-Escalation von einem gewöhnlichen unprivilegierten Account zu vollständigen Root-Rechten. Das allein macht die Lücke zu einem klassischen Zweitstufen-Baustein: Wo immer ein Angreifer bereits irgendeine Form von lokalem Codeausführungs-Fußabdruck hat — eine Webshell, ein kompromittiertes Deployment, ein Container-Breakout, eine bösartige App auf einem Android-Gerät — erlaubt Bad Epoll den Sprung zu vollständiger Systemkontrolle. Auf Multi-Tenant-Systemen (gemeinsam genutzte Hosting-Kernel, CI/CD-Runner, Kubernetes/K3s-Nodes mit nicht vertrauenswürdigen Workloads) bricht das die Isolation zwischen Mietern vollständig.

Mehrere Quellen berichten zudem, dass der Exploit geeignet ist, Chromes Renderer-Sandbox zu umgehen — nicht weil die Sandbox selbst fehlerhaft wäre, sondern weil eine Kernel-Schwachstelle unterhalb jeder Nutzerraum-Isolation liegt und diese damit grundsätzlich aushöhlen kann. Das ist relevant für jede Verteidigungsstrategie, die sich auf Sandboxing oder Container-Isolation als alleinige Schutzschicht verlässt, ohne den darunterliegenden Kernel selbst aktuell zu halten.

Positiv einzuordnen: Bislang liegt keine bestätigte Ausnutzung in freier Wildbahn vor, und die Lücke steht nicht in der CISA-KEV. Das öffentliche, mit ~99% Erfolgsquote funktionierende Exploit-Tooling senkt die Einstiegshürde für Angreifer jedoch erheblich — die Zeit bis zu einer ersten bewaffneten Kampagne dürfte kurz sein, sobald der Patch-Druck auf ungepatchte Systeme steigt.

Mitigation / Sofortmaßnahmen

Eine Konfigurationsabschaltung von epoll existiert nicht — der Mechanismus ist zu zentral für den Netzwerk-Stack, um ihn auszuschalten. Der Patch ist die einzige belastbare Abhilfe:

• Debian trixie:apt update && apt install linux-image-$(uname -r) bzw. die passende Meta-Paketvariante — stellen Sie sicher, dass Version 6.12.95-1 oder höher aus der Security-Suite installiert ist (DSA-6381-1). Debian bookworm/bullseye benötigen keinen Patch für diese CVE.
• Ubuntu 24.04/25.10/26.04 LTS:apt update && apt upgrade für das jeweilige Kernel-Paket (linux-generic, linux-aws, linux-azure, linux-gcp, linux-ibm, linux-nvidia je nach Umgebung), sobald das zugehörige USN veröffentlicht ist — prüfen Sie ubuntu.com/security/CVE-2026-46242 auf den aktuellen Rollout-Stand vor dem Wartungsfenster.
• RHEL-Familie (CloudLinux/AlmaLinux 9/10): Kernel-Update über dnf update kernel bzw. das jeweilige Patch-Management einspielen. Falls Sie KernelCare/Livepatching nutzen: Der Fix wurde zum Zeitpunkt der von uns geprüften Quellen unter KCARE-27500 noch als „in Analyse“ geführt — prüfen Sie den aktuellen Status direkt beim Anbieter, bevor Sie sich allein darauf verlassen.
• Generische/Custom-Kernel: Stellen Sie sicher, dass Ihr Kernel-Build den Fix-Commit a6dc643c6931 enthält (Bestandteil von Linux 7.1-rc1 und aller nachgelagerten Backports).
• Kompensierend, bis gepatcht ist: Reduzieren Sie lokale Codeausführung durch nicht vertrauenswürdige Parteien so weit wie möglich — keine ungeprüften Shell-Zugänge, keine gemeinsam genutzten Kernel für nicht vertrauenswürdige Container- oder CI-Workloads, bis der Patch eingespielt ist.

Detection / Prüfung

Drei Ansätze, kombinierbar:

1. Patch-Stand prüfen:uname -r gegen den Fixed-Stand Ihrer Distribution abgleichen (Debian trixie: ≥ 6.12.95-1; Debian sid: ≥ 7.1.3-1). Auf RHEL-Familie mit installiertem kernel-devel: grep -n 'epi_fget\|__free(fput)' /usr/src/kernels/$(uname -r)/fs/eventpoll.c — taucht epi_fget in ep_remove() auf, ist der Fix enthalten.
2. Verhaltensindikatoren beobachten: Unprivilegierte Prozesse, die in kurzer Folge sehr viele epoll-Instanzen und Timerfds anlegen und wieder schließen (auditd-Regel auf gehäufte epoll_create1/timerfd_create-Aufrufe abseits bekannter Dienste); Kernel-Oops-Meldungen mit Bezug zu ep_show_fdinfo, ep_clear_and_put oder ep_eventpoll_release; unerklärte Kernel-Panics oder Reboots auf Multi-Core-Hosts ohne Konfigurations- oder Hardwareänderung.
3. Kontrollierte Verifikation: Der öffentliche PoC (github.com/J-jaeyoung/bad-epoll) lässt sich in einer isolierten Lab-/Staging-Umgebung gegen einen konkreten Kernel-Build testen, um vor einem Wartungsfenster zu verifizieren, ob dieser Build verwundbar ist — niemals gegen Produktivsysteme einsetzen.

Betreiberempfehlung

Heute handeln, wenn: Sie Multi-Tenant-Linux-Hosts, gemeinsam genutzte CI/CD-Runner, Container-Hosts mit nicht vertrauenswürdiger lokaler Codeausführung oder Kubernetes/K3s-Nodes mit nicht vertrauenswürdigen Workloads betreiben — patchen Sie den Kernel oder spielen Sie das entsprechende Livepatch noch vor dem nächsten regulären Wartungsfenster ein. Ein öffentlicher, mit ~99% Erfolgsquote funktionierender Exploit macht das zu einer Same-Day-Änderung, nicht zu einer geplanten.

Beobachten (nicht dringend), wenn: Ihre Kernel auf Debian bookworm/bullseye oder Ubuntu 22.04 und älter gepinnt sind und kein kurzfristiges Upgrade ansteht — diese sind nach aktuellem Kenntnisstand nicht betroffen, ein Upgrade-Pfad auf einen unterstützten, gepatchten Kernel sollte dennoch eingeplant werden, da ältere Kernel-Zweige irgendwann aus dem Support fallen.

Für Android-Geräteflotten (MDM-verwaltet): Prüfen Sie den herstellerspezifischen Android-Security-Bulletin für den jeweiligen Geräte-Kernel-Branch. Eine öffentliche LPE mit Root-Implikationen ist auch ohne bestätigte In-the-Wild-Ausnutzung eine Priorität fürs Mobile-Device-Management.

Fazit

Bad Epoll ist kein 48-Stunden-Fund, aber ein Fund, der es aus gutem Grund trotzdem auf diesen Blog schafft: eine Use-after-Free-Lücke im Kernel-Herzstück jedes modernen Netzwerkservers, ein öffentlicher Exploit mit rund 99% Erfolgsquote, Reichweite von Linux-Servern über Desktops bis Android — und Distributions-Patches, die genau diese Woche ausrollen. Wo lokale Codeausführung durch nicht vertrauenswürdige Parteien möglich ist, sollte der Kernel-Patch Vorrang vor dem nächsten regulären Wartungsfenster bekommen.

Quellen

• NVD — CVE-2026-46242
• Red Hat — CVE-2026-46242 Advisory
• Debian Security Tracker — CVE-2026-46242 (DSA-6381-1)
• Ubuntu Security — CVE-2026-46242
• Öffentlicher PoC — J-jaeyoung/bad-epoll
• TuxCare — Understanding Bad Epoll
• The Hacker News — New "Bad Epoll" Linux Kernel Flaw