Eine neue Linux-Kernel-Lücke namens Dirty Frag verschafft jedem unprivilegierten lokalen Nutzer mit einem einzigen Befehl Root-Rechte. Das BSI hat am 19. Mai 2026 die zugehörige Sicherheitswarnung aktualisiert. Betroffen sind nahezu alle Linux-Distributionen, dazu Container und Cloud-Workloads. Ein öffentlicher Proof-of-Concept ist im Umlauf.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Stress? Im April fühlte sich die Linux-Kernel-Sicherheitslage noch entspannt an. Vier Wochen später stehen zwei eskalierende Schwachstellen im Raum, und der zweite Bug umgeht jede bisherige Schutzmaßnahme.
- Dirty Frag verkettet zwei CVEs: CVE-2026-43284 (xfrm-ESP Page-Cache Write, CVSS 8,8) und CVE-2026-43500 (RxRPC Page-Cache Write, CVSS 7,8)
- Entdeckt von Sicherheitsforscher Hyunwoo Kim (V4bel), offengelegt am 7. Mai 2026
- Deterministischer Logikfehler, keine Race-Condition, hohe Erfolgsrate, kein Kernel-Panic-Risiko
- Betrifft alle großen Distributionen: RHEL, AlmaLinux, Debian, Ubuntu, SUSE, openSUSE, Proxmox VE
- BSI hat am 19. Mai 2026 die Warnung aktualisiert, Patches in Mainline (f4c50a4034e6, aa54b1d27fe0) verfügbar
Was unterscheidet Dirty Frag von Dirty Pipe und Copy Fail?
Dirty Frag schließt eine Lücke, die der gleichen Bug-Klasse angehört wie Dirty Pipe (CVE-2022-0847) und Copy Fail (CVE-2026-31431). Der Unterschied liegt in der Granularität und der Robustheit der Ausnutzung. Dirty Pipe nutzte einen schmalen Race-Condition-Pfad, Copy Fail begrenzte den Schreibvorgang auf vier Bytes. Dirty Frag erlaubt das Schreiben beliebiger angreiferkontrollierter Klartextdaten an beliebiger Offset-Position in einem Schuss.
Die Schwachstelle liegt im In-Place-Entschlüsselungspfad der Kernel-Module esp4, esp6 (IPsec/ESP) und rxrpc (AFS-Dateisystem-Protokoll). Trägt ein Socket-Buffer Paged Fragments, die nicht im Kernel-Eigentum stehen, etwa via splice(2), sendfile(2) oder MSG_SPLICE_PAGES, dann entschlüsselt der Empfangspfad direkt über extern referenzierte Speicherseiten. Damit lässt sich Klartext eines anderen Prozesses überschreiben.
Die zweite Linux-Root-Lücke binnen vier Wochen ist das deutlichste Signal, dass KI-gestützte Vulnerability-Forschung den Kernel jetzt systematisch durchforstet. Ein Bug aus dem Januar 2017 fällt 2026 auf. Wer als deutscher Hoster oder Mittelständler immer noch ungetestet vom Vendor-Erratum zum Vendor-Erratum läuft, lebt mit einem strukturellen Risiko.
— Markus Seyfferth, Chefredakteur Dr. Web
Welche Systeme sind im Risiko?
Die Antwort lautet kurz: nahezu alle. Die betroffenen Module sind in den Default-Kernel-Paketen aller großen Enterprise-Distributionen aktiviert. Die ESP-Variante steckt seit Januar 2017 im Kernel (Commit cac2661c53f3), die RxRPC-Variante seit Juni 2023. Container-Workloads sind doppelt belastet, weil Docker, containerd und die meisten Kubernetes-Pods standardmäßig den Zugriff auf AF_KEY-, XFRM-Netlink- und AF_RXRPC-Sockets erlauben. Eine Kompromittierung eines einzelnen Containers eskaliert damit auf Host-Root.
Cloud-Provider und Hoster mit Multi-Tenant-Setups stehen besonders im Fokus. Wer auf eine Compromise-of-One-Tenant-Strategie als unrealistisch gesetzt hat, sollte die Bedrohungsmodellierung neu aufmachen. Der aktuelle BSI Cybersicherheitsmonitor 2026 nennt 27 Prozent der deutschen Internetnutzer als bereits Geschädigte, die Schadensbilanz im KMU-Segment wächst überproportional.
Wie patchen Sie kurzfristig und richtig?
Drei Maßnahmen stehen im Raum, abhängig vom Anwendungsprofil.
1. Kernel-Update einspielen
Die Mainline-Patches sind verfügbar (f4c50a4034e6 für xfrm-ESP, aa54b1d27fe0 für rxrpc). Die Distributoren ziehen nach. SUSE veröffentlichte SUSE-SU-2026:2010-1 am 19. Mai 2026, Debian-Updates liefen am 18. Mai, openSUSE-Updates am 17. und 18. Mai. Red Hat Enterprise Linux, Oracle Linux und Rocky Linux folgten am 13. Mai im Bulletin RHSB-2026-003. Für AlmaLinux stehen die Patches seit dem 8. Mai in den Produktionsspiegeln.
2. Module blacklisten als Übergangslösung
Solange das Kernel-Update nicht eingespielt ist, lassen sich die betroffenen Module deaktivieren. Drei Zeilen in /etc/modprobe.d/dirtyfrag.conf reichen aus:
Anschließend per rmmod esp4 esp6 rxrpc entladen und mit lsmod prüfen. Wichtig: IPsec-Verbindungen über StrongSwan sowie AFS-Setups mit RxRPC fallen mit dieser Mitigation aus. Die Mitigation ist kein dauerhafter Ersatz für den Patch.
3. Live-Patching prüfen
Für produktive Systeme ohne mögliches Wartungsfenster bieten Anbieter wie KernelCare oder Ubuntu Livepatch ein Live-Patching ohne Neustart an. KernelCare hat Live-Patches binnen 24 Stunden nach Disclosure für die gesamte EL8-Familie ausgerollt, EL9, Ubuntu, Debian und Proxmox folgten in derselben Welle.
Warum kommt der nächste Linux-Root garantiert?
Beide Bugs lagen jahrelang im Kernel, einer seit acht Jahren. Die Sysdig Threat Research Team vermutet KI-gestützte Vulnerability-Forschung als Treiber. Microsoft-Engineering-Chef Tom Gallagher hat eine ähnliche Vermutung für die parallel laufende Office-Patch-Welle geäußert. Die nächste Klasse-Lücke ist nur eine Frage von Wochen.
Für IT-Verantwortliche bedeutet das: Patch-Disziplin allein reicht nicht mehr. Die Cybersecurity-Grundlagen für KMU verlangen ein systematisches Monitoring der Kernel-Erratum-Lage, einen klar definierten Patch-SLA und eine Awareness-Schulung gegen die parallel laufende KI-Phishing-Welle. Die CISO-Studie 2026 dokumentiert, dass 57 Prozent der Konzerne über das Endgerät gefallen sind. Lokale Root-Eskalation auf einem kompromittierten Workstation-Container ist genau der zweite Schritt einer typischen Angriffskette.
Mehr Newshunger?
