CVE-2026-46300 „Fragnesia": Dirty-Frag-Mitigation greift bereits
Fragnesia (CVE-2026-46300) sitzt im selben XFRM-ESP-in-TCP-Pfad wie Dirty Frag — die seit dem 7. Mai aktive modprobe-Blacklist auf esp4, esp6 und rxrpc schützt rack::SPEED-Server nahtlos.
Die heute öffentlich gewordene Linux-Kernel-Schwachstelle „Fragnesia” (CVE-2026-46300) sitzt im selben Code-Pfad wie Dirty Frag — XFRM-ESP-in-TCP über die Module esp4, esp6 und rxrpc. Die modprobe-Blacklist, die wir am 7. Mai gegen Dirty Frag ausgerollt haben, war zum Zeitpunkt der Disclosure noch auf allen Maschinen aktiv und greift damit nahtlos auch gegen Fragnesia. Wir mussten kein zweites Mal eingreifen.
Was die Lücke macht
Fragnesia ist eine lokale Privilege-Escalation im XFRM-ESP-in-TCP-Stack: ein unprivilegierter lokaler Nutzer kann beliebige Bytes in den Page-Cache von Read-Only-Dateien schreiben und sich darüber Root-Rechte verschaffen. Der veröffentlichte Proof-of-Concept zielt direkt auf /usr/bin/su — ein 192-Byte-ELF-Stub wird in den Page-Cache der Binary geschrieben, der nächste su-Aufruf führt ihn als Root aus. Im Gegensatz zu Dirty Frag braucht Fragnesia keine Race Condition, der Angriff ist deterministisch reproduzierbar.
Wie Dirty Frag ist die Lücke distributionsübergreifend: AlmaLinux, Amazon Linux, Debian, Red Hat, SUSE und Ubuntu haben jeweils eigene Advisories veröffentlicht. CVSS-Score: 7,8 (hoch). Voraussetzung bleibt lokaler Shell-Zugriff — aus dem Internet ist Fragnesia nicht direkt ausnutzbar.
Hintergründe und technische Details:
- Help Net Security: Fragnesia spawned by Dirty Frag patch
- TuxCare: Fragnesia in the Dirty Frag family
- CloudLinux: Fragnesia mitigation and kernel update
- AlmaLinux: Fragnesia patches released
Was wir konkret getan haben
Im Kern: nichts Zusätzliches — und das war der ganze Punkt. Die modprobe-Blacklist auf esp4, esp6 und rxrpc war seit dem Dirty-Frag-Rollout am 7. Mai durchgängig auf allen rack::SPEED cPanel- und Plesk-Maschinen aktiv. Fragnesia trifft genau diese drei Module, also war der Angriffsvektor zum Disclosure-Zeitpunkt bereits gekappt.
Nach Bekanntwerden der neuen Lücke haben wir gegengeprüft: pro Maschine kurzer Check, dass die Blacklist tatsächlich noch greift und keines der Module zwischenzeitlich nachgeladen wurde. Ergebnis war flächendeckend sauber. Auf Servern mit Imunify360 läuft die zusätzliche Script-Blacklist aus der Dirty-Frag-Welle ebenfalls unverändert weiter — zweite Verteidigungslinie, ohne Nachjustierung.
Nächster Schritt: Kernel-Patch
Wie bei Dirty Frag bleibt die Mitigation eine Zwischenlösung. CloudLinux und die anderen Distributionen ziehen die Fragnesia-Fixes in dieselben Kernel-Builds, die ohnehin für den Dirty-Frag-Patch in Arbeit waren. Sobald die Pakete veröffentlicht sind, rollen wir sie auf allen Servern aus und starten die Maschinen neu. Die Blacklist bleibt bis zum Reboot aktiv. Den Wartungs-Termin pro betroffener Maschine kommunizieren wir wie üblich vorab über Ticket- bzw. Status-Benachrichtigung — den Live-Stand findest du auf der rack::SPEED Status-Page.
Was du selbst tun solltest
Aktiv tun musst du nichts. Auf einem rack::SPEED Managed-Hosting-Server bist du durch die durchgängig aktive Blacklist und die Account-Isolation der Plattform gegen den lokalen Angriff abgesichert. Wer einen eigenen Managed Server mit Shell-Accounts betreibt, ist Teil unseres Sweeps — die Mitigation ist dort genauso aktiv wie auf den Hosting-Maschinen.
Eine alte Mitigation, die eine neue Lücke abfängt, bevor sie öffentlich wird — genau dafür haben wir sie auch nach dem Dirty-Frag-Wochenende stehen lassen.