Dirty Frag Zero-Day: Root-Zugriff auf allen wichtigen Linux-Distributionen

Stellen Sie sich eine Brücke vor, die fast ein Jahrzehnt lang sicher befahren wurde, bis ein Bauingenieur an einem Donnerstagmorgen genau die Last und den Winkel veröffentlicht, der sie zum Einsturz bringt. In dieser Situation wachten Linux-Flottenbetreiber am 8. Mai auf. Ein Forscher namens Hyunwoo Kim veröffentlichte Dirty Frag, eine lokale Rechteausweitung, die jeden unprivilegierten Benutzer auf praktisch jeder relevanten Distribution zum Root macht – und das Embargo war bereits am Vortag gebrochen worden.

Die Brückenmetapher wird in diesem Artikel noch öfter auftauchen, denn Dirty Frag ist kein einzelner gerissener Träger. Es sind zwei Fehler im Deck, miteinander verkettet, und der Kernel trägt diese Last bereits seit etwa 2017.

Was ist passiert

Am 8. Mai 2026 um 03:45 Uhr veröffentlichte Sicherheitsforscher Hyunwoo Kim vollständige Dokumentation und einen funktionierenden Proof-of-Concept für Dirty Frag, einen lokalen Root-Exploit, der mit einem einzigen Befehl auf den meisten großen Linux-Distributionen funktioniert. Wie BleepingComputer berichtete, wurde der Bug vor etwa neun Jahren in die algif_aead-Schnittstelle des Kernels eingeführt und wartet seitdem still im Mainline-Kernel.

Kim wollte es nicht so herausgeben. Er hatte über [email protected], die standardmäßige Pre-Disclosure-Liste für genau diese Art von herstellerübergreifender Koordination, mit den Distro-Maintainern zusammengearbeitet. Dann veröffentlichte am 7. Mai eine unbekannte dritte Partei unabhängig den Exploit, und das Embargo war dahin.

„Da das Embargo derzeit gebrochen ist, existiert kein Patch oder CVE", schrieb Kim. „Nach Rücksprache mit den Maintainern auf [email protected] und auf deren Wunsch wird dieses Dirty Frag-Dokument veröffentlicht." Übersetzt: Sobald die Katze aus dem Sack ist, schadet das Zurückhalten des technischen Berichts nur den Verteidigern.

Bis 09:58 Uhr EDT am selben Tag wurden die beiden zugrunde liegenden Fehler in CVE-Einträge aufgenommen: CVE-2026-43284 für die xfrm-ESP Page-Cache Write-Schwachstelle und CVE-2026-43500 für die RxRPC Page-Cache Write-Schwachstelle. Die Betroffenen-Liste liest sich wie ein Aufgebot produktiver Linux-Systeme: Ubuntu, Red Hat Enterprise Linux, CentOS Stream, AlmaLinux, openSUSE Tumbleweed und Fedora. Zum Zeitpunkt der Veröffentlichung hatte keine von ihnen einen Patch.

Und das alles, während alle noch mitten im Rollout für Copy Fail stecken, der vorherigen Root-Eskalation, die bereits aktiv ausgenutzt wird.

Technische Analyse

Dirty Frag gehört zur selben Bug-Klasse wie Dirty Pipe und Copy Fail, trifft aber einen anderen Träger der Brücke. Während Dirty Pipe die Splice/Pipe-Page-Cache-Infrastruktur missbrauchte, greift Dirty Frag das Fragment-Feld einer separaten Kernel-Datenstruktur an, die über algif_aead exponiert wird – der benutzerraumseitigen Crypto-Schnittstelle für authentifizierte Verschlüsselung.

Der Exploit verkettet zwei verschiedene Page-Cache-Write-Primitives. Die erste ist der xfrm-ESP Page-Cache Write-Bug (CVE-2026-43284), erreichbar über den IPsec-ESP-Transform-Code. Die zweite ist der RxRPC Page-Cache Write-Bug (CVE-2026-43500), erreichbar über den AFS-artigen RPC-Stack. Jeder für sich ist ein Memory-Corruption-Einstiegspunkt. Verkettet ermöglichen sie es einem unprivilegierten Prozess, geschützte Systemdateien im Page Cache zu modifizieren, ohne die Dateiberechtigungsprüfungen zu durchlaufen, die die VFS-Schicht eigentlich erzwingen soll. Das bedeutet: Eine SUID-Binärdatei, /etc/passwd oder eine andere privilegierte On-Disk-Datei, die aktuell gecacht ist, umschreiben – und man ist Root.

Hier der Teil, der jeden kernel-interessierten Ingenieur aufhorchen lassen sollte. Kim beschreibt Dirty Frag als „einen deterministischen Logikfehler, der nicht von einem Timing-Fenster abhängt, keine Race Condition erforderlich ist, der Kernel beim Scheitern des Exploits nicht abstürzt und die Erfolgsrate sehr hoch ist." Das ist das ingenieurtechnische Albtraumszenario. Race-Condition-Exploits sind unzuverlässig, lautstark und lassen den Host beim Scheitern oft abstürzen, was EDR-Systemen etwas zum Anschlagen gibt. Ein deterministischer Logikfehler ist das Gegenteil: leise, wiederholbar, skriptbar und einsetzbar in der Post-Exploitation-Phase jedes handelsüblichen Malware-Kits.

Wer jemals Kernel-Module für eine Produktionsflotte ausgeliefert hat, kennt die nüchterne Wahrheit: Die gefährlichsten Bugs sind kein Memory-Safety-Theater, sondern Logikfehler in Schnittstellen, die niemand prüft, weil sie wie Verbindungscode aussehen. algif_aead ist genau diese Art Verbindungscode. Er steht seit neun Jahren auf der Brücke, weil er seine Aufgabe erfüllt und niemand einen Grund hatte, den Fragment-Handling-Pfad genau unter die Lupe zu nehmen.

Wer ist betroffen

Die direkte Antwort: Jeder, der Multi-Tenant-Linux betreibt. Die präzisere Antwort hängt davon ab, wer Ihre unprivilegierten Benutzer sind.

Shared Hosting, CI-Runner, Kubernetes-Nodes mit nicht vertrauenswürdigen Workloads, Universitätscluster, Bug-Bounty-Sandboxes und jede iGaming- oder Fintech-Plattform, die kundenkontrollierten Code auf gemeinsam genutzten Hosts ausführt: Das ist das Deck der Brücke. Eine lokale Rechteausweitung ist weit gefährlicher, wenn „lokal" einen Mandanten einschließt. Für Kubernetes-Betreiber im Besonderen bedeutet ein Container-Escape plus Dirty Frag eine vollständige Node-Übernahme, und von dort aus sind die Kubelet-Anmeldedaten und auf diesem Node gemounteten Secrets verloren.

Zahlungs- und Handelsunternehmen mit strikten Change-Control-Fenstern befinden sich in einer schwierigen Lage. Kernel-Patching erfordert Neustarts, Neustarts erfordern Wartungsfenster, und Wartungsfenster in regulierten Umgebungen erfordern Genehmigungen. Die von Kim bereitgestellte Maßnahme – das Entfernen der Kernel-Module esp4, esp6 und rxrpc – ist ein echter Fix, aber nicht kostenlos. Sie unterbricht IPsec-VPNs und AFS-Dateisysteme. Wenn Ihre Site-to-Site-Konnektivität auf IPsec basiert, ist das Entfernen von ESP keine Einzeiler-Lösung, sondern eine Architekturänderung.

Bundesbehörden, die noch der Copy-Fail-Deadline nachjagen, sind in der schlechtesten Lage. CISA hat Copy Fail am vorherigen Freitag in seinen Known Exploited Vulnerabilities Catalog aufgenommen, mit einer Frist bis zum 15. Mai zur Absicherung föderaler Linux-Geräte. CISAs Standardaussage zu dieser Bug-Klasse – dass sie „ein häufiger Angriffsvektor für böswillige Cyberakteure ist und erhebliche Risiken für das föderale Unternehmen darstellt" – gilt nun für zwei gleichzeitige ungepatchte Root-Lücken. Und Pack2TheRoot, im April nach einem Jahrzehnt im PackageKit-Daemon gepatcht, macht drei in etwa dreißig Tagen.

Das Muster ist es, was CTOs beunruhigen sollte. Alter Code, tief im Stack, gefunden von einzelnen Forschern, der schneller fällt, als Enterprise-Patch-Zyklen aufnehmen können.

Leitfaden für Sicherheitsteams

Diese Woche, nicht im nächsten Sprint:

Entscheiden Sie zunächst, ob Sie die Module entfernen können. Führen Sie lsmod | grep -E 'esp4|esp6|rxrpc' auf Ihrer gesamten Flotte aus. Wenn die Antwort „geladen, aber ungenutzt" lautet, wenden Sie Kims Maßnahme an: Sperren Sie sie in /etc/modprobe.d/ und entfernen Sie die aktiven mit rmmod. Wenn Sie IPsec oder AFS nutzen, ist das nicht möglich, und Sie benötigen stattdessen eine kompensierende Kontrolle.

Schränken Sie zweitens ein, wer auf algif_aead zugreifen kann. Die Schnittstelle wird durch AF_ALG-Sockets abgesichert. seccomp-Profile, die socket(AF_ALG, ...) für nicht vertrauenswürdige Workloads ablehnen, eliminieren die Angriffsfläche für diesen Prozessbaum. Für Container-Plattformen ist das eine Änderung der Pod Security Policy oder von gVisor/Kata. Führen Sie das Audit jetzt durch, solange alle aufmerksam sind.

Behandeln Sie drittens Ihre CI-Runner und kurzlebige Rechenkapazität als standardmäßig kompromittiert, bis der Patch eingespielt ist. Rotieren Sie alle langlebigen Anmeldedaten, auf die diese Hosts zugreifen können. Wer nach einer Runner-Übernahme aufgeräumt hat, weiß: Die Aufräumkosten übersteigen die Patch-Kosten um eine Größenordnung.

Überwachen Sie viertens Ihre Erkennung. Dirty Frag ist deterministisch und leise, sodass das übliche „Kernel Panic Spike"-Signal Sie nicht retten wird. Achten Sie auf unerwartete AF_ALG-Socket-Erstellung durch Nicht-Crypto-Workloads, anomale SUID-Binärdatei-Modifikationen und Page-Cache-Anomalien, falls Ihr eBPF-Tooling das unterstützt. Ordnen Sie das Verhalten MITRE ATT&CK T1068 zu und schreiben Sie die Erkennung, bevor der Exploit in ein Botnet eingebaut wird – nicht danach.

Lassen Sie fünftens Ihren Kernel-Patch-Zyklus testen. Wenn Upstream den Fix liefert, wollen Sie das Team sein, das in 48 Stunden ausliefert, nicht das, das ein Change-Ticket erstellt.

Wichtige Erkenntnisse

• Dirty Frag ist ein deterministischer, Ein-Befehl-lokaler Root-Exploit, der Ubuntu, RHEL, CentOS Stream, AlmaLinux, openSUSE Tumbleweed und Fedora betrifft – ohne Patches zum Zeitpunkt der Offenlegung.
• Er verkettet CVE-2026-43284 (xfrm-ESP) und CVE-2026-43500 (RxRPC) über die neun Jahre alte algif_aead-Schnittstelle – keine Race Condition erforderlich.
• Das Embargo brach am 7. Mai, als eine unbekannte dritte Partei den Exploit veröffentlichte, was Kim zwang, einen Tag später die vollständige Dokumentation freizugeben.
• Die Maßnahme, die Module esp4, esp6 und rxrpc zu entfernen, funktioniert, unterbricht jedoch IPsec-VPNs und AFS – für Produktionsnetzwerke also nicht kostenlos.
• Zusammen mit Copy Fail (bereits im CISA KEV mit föderaler Frist bis 15. Mai) und dem April-Bug Pack2TheRoot ist dies der dritte tiefgreifende Linux-Root-Bug in etwa dreißig Tagen.

Zurück zur Brücke. Neun Jahre Verkehr, zwei gerissene Träger, und der Ingenieur, der den Versagensmodus fand, wurde mitten in der Präsentation vom Podium gedrängt. Das Deck trägt noch immer Last. Ob es Ihre in den nächsten zwei Wochen trägt, hängt davon ab, was Sie vor Freitag tun.