Dirty Frag CVE-2026-43284 und 43500: Linux-Kernel-Lücke per Mitigation entschärft

Die heute öffentlich gewordene Linux-Kernel-Schwachstelle „Dirty Frag” wurde auf allen rack::SPEED cPanel- und Plesk-Servern soeben per Mitigation entschärft. Der vollständige Kernel-Patch ist noch nicht freigegeben — sobald er verfügbar ist, spielen wir ihn ein und starten neu.

Was die Lücke macht

„Dirty Frag” verkettet zwei Bugs im Linux-Kernel-Netzwerk-Stack — einen im xfrm-ESP-Code (Crypto/IPsec) und einen im RxRPC-Subsystem. Über beide lassen sich Page-Cache-Writes erzwingen, die ein lokal angemeldeter Nutzer ausnutzen kann, um Root-Rechte zu erlangen. Voraussetzung ist ein Account mit Shell-Zugriff auf der Maschine — aus dem Internet ist die Lücke nicht direkt ausnutzbar.

Der xfrm-ESP-Bug schlummert seit Januar 2017 im Code (rund neun Jahre), der RxRPC-Bug seit Juni 2023. Getestet wurde der Exploit gegen Ubuntu 24.04, RHEL 10.1, AlmaLinux 10, openSUSE Tumbleweed, CentOS Stream 10 und Fedora 44 — die Trefferquote ist nach Angaben des Forschers „sehr hoch”, weil es sich um deterministische Logik-Bugs handelt, nicht um Race Conditions.

Stand 7. Mai 2026 ist noch keine CVE-Nummer zugewiesen — das Embargo wurde gebrochen, bevor ein koordinierter Patch freigegeben war. Forscher: Hyunwoo Kim (@v4bel). Details und Proof-of-Concept stehen im GitHub-Repository des Forschers und in der CloudLinux-Mitigations-Notiz.

Was wir konkret getan haben

Heute, unmittelbar nach Bekanntwerden, haben wir auf allen Maschinen mit cPanel und Plesk die offizielle Mitigation eingespielt: die drei Kernel-Module esp4, esp6 und rxrpc werden per modprobe-Blacklist daran gehindert, beim Start geladen zu werden. Bereits geladene Instanzen wurden entladen, soweit es ohne Reboot ging.

Praktisch heißt das: der Angriffsvektor ist gekappt, weil die verwundbaren Code-Pfade im laufenden Kernel nicht mehr aktiv sind. IPsec-Tunnel funktionieren während der Mitigation nicht — auf Hosting-Servern ist das in aller Regel irrelevant, weil dort kein IPsec terminiert wird. Falls du auf einem rack::SPEED Managed Server eine eigene IPsec-Konfiguration fährst, melde dich kurz, wir besprechen den Einzelfall.

Auf Servern mit Imunify360 greift zusätzlich eine Script-Blacklist, die das Laden des Exploit-Skripts auf Account-Ebene unterbindet — eine zweite Verteidigungslinie für die Hosting-Plattform.

Nächster Schritt: Kernel-Patch

Eine Mitigation ist kein vollständiger Fix. Sobald CloudLinux und die anderen Distributionen die regulären Kernel-Patches freigeben (laut CloudLinux-Blog „in active build/test”, Stand heute), spielen wir sie ein und starten die Maschinen erneut. Die Mitigation bleibt bis dahin aktiv. Den Reboot-Termin pro betroffener Maschine kommunizieren wir wie üblich vorab über Ticket- bzw. Status-Benachrichtigung.

Was du selbst tun solltest

Aktiv tun musst du nichts. Auf einem rack::SPEED Managed-Hosting-Server bist du durch die Mitigation und die ohnehin greifende Account-Isolation der Plattform gegen den lokalen Angriff abgesichert. Wer einen eigenen Managed Server betreibt und Shell-Accounts ausgibt, sollte prüfen, ob die Mitigation auf seiner Maschine bereits aktiv ist — sie ist Teil unseres Sweeps. Sonderfälle (eigenes IPsec-Setup, Custom-Kernel) über das Kontaktformular oder telefonisch unter +49 (0)2102 305 84 30 melden.

Den Live-Status der Patch-Welle pflegen wir auf der rack::SPEED Status-Page.

Erst absichern, dann sauber patchen. In der Reihenfolge, weil der Patch noch nicht da ist.