Fragnesia (CVE-2026-46300) — die dritte XFRM-LPE in drei Wochen

TL;DR — die 90-Sekunden-Zusammenfassung

Was ist Fragnesia?

Eine neue lokale Linux-Kernel-Privilege-Escalation (CVE-2026-46300) im espintcp-ULP-Pfad. Derselbe XFRM/ESP-Komplex wie Dirty Frag — aber ein separater Bug, nicht dieselbe Ankündigung.

Wie ernst?

Trivial. Unprivilegierter lokaler User wird in einem einzigen Kommando zu root. Public PoC verfügbar. Keine Race-Condition nötig — deterministische Schreibprimitive.

Wer ist betroffen?

Praktisch jeder moderne Linux-Kernel, bei dem die Module esp4, esp6 oder rxrpc autoload-bar sind. CloudLinux 7h, 8, 9, 10 sind betroffen; AlmaLinux 9 und 10 ebenfalls (CL9/CL10 nutzen den AlmaLinux-Kernel). Ubuntu-Status zu allen aktiven Kerneln: „Needs evaluation“.

Was tun — sofort?

Mitigation identisch zu Dirty Frag: esp4, esp6, rxrpc per /etc/modprobe.d/-Eintrag blacklisten und unloaden. Zusätzlich Page-Cache droppen, weil der Exploit Systembinäries (z.B. /usr/bin/su) im Page-Cache überschreibt — die Mitigation allein reinigt diese Manipulationen nicht.

Was ist anders als bei Dirty Frag?

Drei Dinge: (1) Schreib-Primitive ist deterministisch statt race-basiert. (2) Exploit ändert beliebige lesbare Dateien im Page-Cache, nicht nur Spezialpfade. (3) Wer die Dirty-Frag-Mitigation schon aktiv hat (esp-Module geblockt), ist auch gegen Fragnesia geschützt — das ist der Glanzpunkt der Bug-Klassen-Mitigation.

Patch-Stand 15.05.2026?

AlmaLinux 9 (5.14.0-611.54.4.el9_7+) und AlmaLinux 10 (6.12.0-124.56.2.el10_1+) sind in Testing. CloudLinux baut darauf auf. KernelCare-Livepatches sind für ELS-/FIPS-Variante CL9 raus, weitere folgen. Upstream-Mainline-Fix: nur im netdev-Tree, noch nicht in linus/master. Ein zusätzlicher Exploit-Pfad wurde am 14.05. identifiziert — die Distributionen bauen aktuell neue Kernel mit erweitertem Fix.

Was wir bei Moselwal getan haben?

Mitigation auf allen Bestandskunden-Hosts aktiv (war schon seit Dirty Frag), drop_caches nach Disclosure als zusätzlichen Schritt ausgeführt. Kernel-Update-Schedule läuft, sobald die Distros den erweiterten Fix freigeben. KernelCare-bestelltes Bestand-Equipment erhält das Livepatch automatisch.

 

Was ist das Problem?

Fragnesia ist ein Logikfehler im Linux-Kernel-Pfad für ESP-in-TCP — dem espintcp-ULP, der IPsec-ESP-Verkehr über TCP-Streams einkapselt (RFC 8229). Der Bug entsteht aus der Reihenfolge zweier Kernel-Operationen, die der Kernel fälschlich kombiniert.

Der Ablauf

1. Ein TCP-Socket wird geöffnet, und der unprivilegierte Prozess spliced via splice(2) oder sendfile(2) Daten aus einer beliebigen lesbaren Datei in die Receive-Queue dieses Sockets. Wichtig: das sind echte File-Pages aus dem Page-Cache — keine Kopie, sondern direkte Referenzen.
2. Anschließend wird derselbe Socket per setsockopt(SOL_TCP, TCP_ULP, “espintcp”) in den ESP-ULP-Modus geschaltet — ohne dass die bereits gequeuten File-Pages dabei verworfen werden.
3. Im ESP-ULP-Pfad behandelt der Kernel ankommende Daten als ESP-Pakete mit AES-GCM-Verschlüsselung. Er beginnt also, die gequeuten File-Pages als ESP-Ciphertext zu interpretieren und in place zu entschlüsseln.
4. Der AES-GCM-Keystream wird XOR-weise auf die File-Pages angewendet. Da der Angreifer den IV-Nonce kontrolliert (Teil der gesendeten ESP-‚Header‘), kann er den Keystream pro Byte vorhersagen.
5. Ergebnis: eine kontrollierte One-Byte-Schreiboperation in den Page-Cache jeder lesbaren Datei pro Trigger-Aufruf. Beliebige andere Prozesse, die anschließend diese Datei lesen, sehen den manipulierten Inhalt — inklusive Privilegierter Prozesse, die /usr/bin/su oder /usr/bin/sudo ausführen.

Warum keine Race-Condition

Im Gegensatz zu klassischen Page-Cache-Race-Exploits (Dirty COW 2016, Dirty Pipe 2022) braucht Fragnesia keine zeitliche Koordination. Der Schreibvorgang ist die natürliche Folge des Kernel-Codepfads. Der Angreifer steuert IV und Klartext-Auswahl deterministisch — die Schreibprimitive landet exakt dort, wo er sie ablegen will.

Was der Public PoC tut

Der von V12-Security veröffentlichte Exploit schreibt einen 192-Byte position-independent ELF-Stub in den Page-Cache-Eintrag von /usr/bin/su. Beim nächsten su-Aufruf (durch den User selbst oder einen anderen Prozess auf demselben Host) führt der Kernel diesen Stub als root aus — in einem einzigen Kommando.

Wer ist betroffen?

Praktisch jeder Linux-Host, der auf einem Standard-Distributionskernel läuft, bei dem die Kernel-Module esp4, esp6 oder rxrpc autoload-bar sind. Das ist die Standardkonfiguration bei nahezu allen populären Distributionen.

Bestätigt betroffen (Stand 15.05.2026)

• CloudLinux 7h, 8, 9, 10 — alle aktiven CL-Linien sind betroffen. CL7 (ohne „h“) ist als einzige Ausnahme nicht betroffen, weil der Kernel das ESP-ULP nicht enthält.
• AlmaLinux 9 und 10 — Upstream-Distribution für CL9/CL10. Patched-Kernel in Testing: 5.14.0-611.54.4.el9_7 (AL9) und 6.12.0-124.56.2.el10_1 (AL10) oder neuer.
• Ubuntu — Canonical hat den Bug als High Priority klassifiziert („trivial local privilege escalation“) und für sämtliche aktiven Kernel-Pakete (linux, linux-aws, linux-azure, linux-gcp, linux-oracle, linux-hwe-*, linux-fips, etc.) den Status „Needs evaluation“ gesetzt. Der Fix ist Stand 13.05. ausschließlich im netdev-Tree, noch nicht in linus/master gemerged.
• Debian, RHEL, SLES, etc. — dieselbe Bug-Klasse, dieselbe Mitigation. Upstream-Patches werden in den nächsten Tagen erwartet.

Nicht betroffen

• Kernels, in denen ESP-in-TCP nicht gebaut wurde — sehr selten außerhalb von hardened Embedded-Systemen.
• Bereits voll gepatchte Kernels (Distro-Update nach 13. bzw. 14.05.2026 — abhängig von der Distribution).
• Hosts mit aktiver Dirty-Frag-Mitigation (modprobe-Blacklist auf esp4/esp6/rxrpc): die ist deckungsgleich zu Fragnesia. Wer Dirty Frag bereits mitigiert hat, ist auch gegen Fragnesia geschützt — muss aber zusätzlich den Page-Cache droppen (siehe Mitigation).

Besondere Risikoprofile

• Shared-Hosting-Stacks mit mehreren mandantischen FE-Usern auf einem Host: jeder lokale User wird zu root — die Mandanten-Trennung kollabiert sofort.
• Container-Hosts mit privilegierten Sidecar-Workloads oder Mount-Strukturen, die Schreibrechte auf den Host-Page-Cache ergeben.
• CI/CD-Worker, auf denen externer (untrusted) Code ausgeführt wird: ein einzelner bösartiger Job wird zu Host-Root.
• Kubernetes-Worker-Nodes, auf denen Pods mit CAP_NET_ADMIN oder direktem Socket-Zugriff laufen — nicht zwingend, aber Risiko erhöht.

Auswirkungen

Die Auswirkungen sind nahezu identisch zu Dirty Frag und Copy Fail, aber das Exploitation-Profil ist schlechter für Defender:

Vollständige Host-Kompromittierung

Jeder lokale User wird in einem einzigen Kommando zu root. Damit kollabieren alle Container-/Mandanten-Grenzen, die auf User-IDs basieren. Auf Shared-Hosting-Plattformen ist die Mandantentrennung sofort hinfällig.

Binär-Manipulation im Page-Cache

Der Exploit ändert nicht nur den Prozess-Speicher — er überschreibt Systembinäries (z.B. /usr/bin/su) im Page-Cache. Sobald ein anderer Prozess die Datei liest, erhält er den manipulierten Inhalt. Das ist persistent für die Dauer des Reboots: erst beim nächsten Disk-Read oder drop_caches wird der originale Inhalt wiederhergestellt.

Forensik-Schaden

Standard-File-Integrity-Tools wie rpm -V, debsums, AIDE oder Tripwire lesen die Datei über den Page-Cache — und sehen also den manipulierten Stub, während die Disk-Prüfsumme korrekt ist. Klassische FIM-Scans erkennen den Angriff nicht, solange der Page-Cache vergiftet ist.

Geringere Detection-Wahrscheinlichkeit als bei Dirty Frag

Anders als bei race-basierten Exploits gibt es bei Fragnesia keine Anzeichen wie Spinlock-Druck, paralleles File-Pounding oder ungewöhnliche Scheduler-Patterns. Der Exploit läuft als gewöhnliche TCP-Verbindung mit ein paar setsockopt-Calls — EBPF-Audit-Regeln, die Race-Symptome triggern, schlagen nicht an.

Im Zusammenspiel mit anderen CVEs

Die Bug-Klasse „XFRM/ESP-Logikfehler“ ist mit Fragnesia jetzt zum dritten Mal in unter drei Wochen aufgetaucht. Es ist statistisch wahrscheinlich, dass weitere CVEs in dieser Schicht folgen werden — entweder als unabhängige Befunde oder als Variationen derselben Logikschicht. Wer die esp4/esp6/rxrpc-Module nicht braucht, sollte sie permanent blacklisten, nicht nur für diesen einen Vorfall.

Mitigation und Sofortmaßnahmen

Quick-Start in zwei Befehlen

Wenn Sie nichts weiter lesen, sondern jetzt handeln müssen:

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"

Der erste Befehl blacklistet die drei verwundbaren Kernel-Module dauerhaft und entlädt sie, falls bereits geladen. Der zweite Befehl droppt den Page-Cache zwingend — sonst bleiben möglicherweise schon vergiftete Binäries im Speicher.

Wer bereits Dirty Frag mitigiert hat

Der erste Befehl ist identisch zur Dirty-Frag-Mitigation. Wenn Sie diese Datei (/etc/modprobe.d/dirtyfrag.conf) bereits angelegt haben, ist Fragnesia ebenfalls geblockt — die Bug-Klasse ist deckungsgleich. Sie müssen aber zusätzlich den Page-Cache droppen, weil zwischen Disclosure von Dirty Frag (07.05.) und Disclosure von Fragnesia (13.05.) Binäries möglicherweise schon manipuliert wurden, auf Hosts wo der Bug genutzt wurde.

Kompatibilität — wer darf die Mitigation NICHT anwenden

esp4/esp6 sind die Kernel-ESP-Transforms für IPsec. Die Mitigation bricht den Kernel-Data-Path für IPsec auf dem betroffenen Host. Nicht anwenden auf:

• VPN-Gateways mit IPsec/strongSwan/Libreswan-Terminierung
• Transit-Router mit kernel-mode IPsec-Tunneln
• Edge-Hosts mit Site-to-Site-IPsec zu Cloud-Providern

Für diese Setups ist der Patch-Pfad (Kernel-Update + Reboot) die einzige Option. Alternativ: Wechsel auf User-Space-IPsec wie strongSwan im kernel=netkey=no-Modus (sehr selten) oder Migration auf WireGuard.

rxrpc ist die AF_RXRPC-Transportschicht und wird nahezu ausschließlich von AFS-Clients benötigt. Auf typischen TYPO3-/Sylius-Hosting-Servern ist sie nicht in Verwendung — hier ist die Blacklist gefahrlos.

Page-Cache zwingend droppen

Auch wenn Sie keine konkrete Exploit-Aktivität auf Ihrem Host vermuten: echo 3 > /proc/sys/vm/drop_caches ist eine billige, jederzeit zumutbare Operation, die garantiert, dass alle Binäries beim nächsten Zugriff frisch von Disk gelesen werden. Performance-Impact: ein paar Sekunden höhere I/O-Last beim nächsten Tool-Start, danach normal.

Wiederherstellung nach Patch

Sobald ein gepatchter Kernel installiert und gebootet ist:

sudo rm /etc/modprobe.d/dirtyfrag.conf
sudo reboot   # optional, damit esp4/esp6 wieder geladen werden können

Wenn Sie keinen IPsec-Workload haben: lassen Sie die Datei einfach drin. Die ESP-Module werden auf typischen Hosts nicht gebraucht, und die Bug-Klasse könnte weitere CVEs nachliefern.

KernelCare — Livepatch ohne Reboot

Für CloudLinux-Hosts mit KernelCare-Subscription: das Livepatch ist Stand 14.05. für ELS-/FIPS-Variante CL9 verfügbar. Update via:

sudo kcarectl --update
kcarectl --patch-info | grep CVE-2026-46300

Weitere Linien folgen in den nächsten Tagen. KernelCare-Patches landen automatisch, sobald sie freigegeben sind.

Detection und Prüfung

Drei Lead-Fragen für die schnelle Triage

1. Sind esp4, esp6 oder rxrpc auf diesem Host geladen? Wenn ja — und Sie nutzen kein kernel-mode IPsec — dann ist der Host exposed.
2. Gab es zwischen dem 07.05. (Dirty Frag Disclosure) und der Mitigation auf diesem Host lokale, unprivilegierte User-Accounts mit Shell-Zugriff? Wenn ja, müssen Sie davon ausgehen, dass su/sudo im Page-Cache potenziell vergiftet sind.
3. Wurde der Page-Cache nach Mitigation gedroppt? Wenn nein, echo 3 > /proc/sys/vm/drop_caches jetzt ausführen.

Schnellprüfung: sind die Module geladen?

lsmod | grep -E '^esp[46]|^rxrpc'

Leere Ausgabe = Module sind nicht geladen, Risiko aktuell niedrig. Ausgabe vorhanden = Module sind aktiv, Mitigation sofort anwenden.

Prüfung: Mitigation tatsächlich aktiv

cat /etc/modprobe.d/dirtyfrag.conf 2>/dev/null
lsmod | grep -E '^esp[46]|^rxrpc'   # sollte leer sein
modprobe esp4 2>&1 | head -1     # sollte 'modprobe: ERROR: ...' liefern

Wenn alle drei Prüfungen das erwartete Bild zeigen (Datei existiert, Module nicht geladen, manuelles Modprobe schlägt fehl), ist die Mitigation wirksam.

Verifikation: ist der Kernel gepatcht?

uname -r

Vergleich gegen den Patch-Stand:

• CL9 / AlmaLinux 9: 5.14.0-611.54.4.el9_7 oder neuer (Testing-Stand 13.05., Production-Promotion läuft)
• CL10 / AlmaLinux 10: 6.12.0-124.56.2.el10_1 oder neuer (Testing-Stand 13.05.)
• Hinweis: Am 14.05. wurde ein zusätzlicher Exploit-Pfad identifiziert. Neue Kernel-Versionen sind in Vorbereitung — vor finalem Patch noch nicht endgültig.

Für KernelCare:

kcarectl --patch-info | grep CVE-2026-46300

Trifft Treffer = Livepatch ist eingespielt.

Forensik: wurden Binäries manipuliert?

Nach drop_caches sind die Page-Cache-Manipulationen weg — aber das heißt auch: Forensik-Hinweise auf dem Disk-Pfad sind im Page-Cache nicht mehr vorhanden. Wer einen Vorfall untersuchen muss, sollte vor dem drop_caches:

# 1. Memory-Dump (auf Hosts mit AVML, LiME oder kdump)
sudo avml /var/log/memory-fragnesia-pre.dump

# 2. Anschließend Page-Cache droppen
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"

# 3. Datei-Integritätsprüfung mit Fresh-Read-Tool
sudo rpm -V coreutils util-linux shadow-utils sudo   # RHEL/CL
sudo debsums -c coreutils util-linux passwd sudo     # Debian/Ubuntu

Wer keinen Memory-Dump braucht, kann drop_caches direkt ausführen — das ist der Standardpfad für alle Produktiv-Hosts ohne aktive Untersuchung.

EBPF-/Falco-Detection

Wegen des fehlenden Race-Patterns sind klassische Race-Detection-Regeln unwirksam. Eine spezifischere Regel prüft auf die ungewöhnliche Sequenz splice/sendfile → setsockopt(TCP_ULP, "espintcp") auf demselben Socket innerhalb kurzer Zeit:

- rule: fragnesia_espintcp_after_splice
  desc: Detect TCP socket transitioning to espintcp ULP after splice/sendfile
  condition: >
    evt.type = setsockopt and
    evt.arg.optname = SO_TCP_ULP and
    evt.arg.optval contains "espintcp" and
    proc.exepath != "/usr/sbin/strongswan" and
    proc.exepath != "/usr/sbin/charon"
  output: "Fragnesia trigger pattern (user=%user.name proc=%proc.exepath fd=%evt.arg.fd)"
  priority: CRITICAL

Die Regel ist als Detection-Indikator gedacht, nicht als primäre Verteidigung — die Mitigation bleibt das primäre Mittel.

Betreiberempfehlung

Operational Decision Block

Empfehlung nach Setup-Typ

Single-Tenant-TYPO3-Hosting ohne Shell-User

Geringes Risikoprofil. Mitigation defensiv anwenden, Page-Cache droppen, Kernel im nächsten regulären Maintenance-Slot updaten. KernelCare ist Empfehlung, aber nicht Notfall.

Shared-Hosting mit mehreren FE-Usern

Hochrisiko. Mitigation und Page-Cache-Drop jetzt, Kernel-Patch innerhalb 24-48h. Vor dem Patch keine neuen User-Sessions erlauben, falls möglich.

Multi-Tenant-Kubernetes-Worker-Nodes

Risikobewertung hängt vom Pod-Security-Profil ab. Pods ohne CAP_NET_ADMIN oder ohne Host-Network können Fragnesia praktisch nicht triggern — aber sobald ein Pod aus dem Container ausbricht oder ein malicious Container läuft, ist der Host kompromittierbar. Mitigation auf Worker-Node-Ebene anwenden, Cluster-Wide-Rollout planen.

VPN-Gateway / IPsec-Konzentrator

Mitigation nicht anwenden. Direkt auf Kernel-Patch-Pfad. Bis dahin: VPN-Service nicht abschalten (das würde Mandanten-Konnektivität kippen), aber die Endpunkt-Authentifizierung sorgfältig auditieren — wer einen IPsec-Tunnel terminieren darf, hat lokalen Socket-Zugriff und damit Fragnesia-Trigger-Möglichkeit.

CI/CD-Runner

Maximalrisiko. Jeder Build-Job ist potenziell ein Angreifer. Mitigation sofort, Page-Cache-Drop, dann Kernel-Patch. Bis Patch verfügbar: Runner mit ephemeralen VMs ersetzen (frische VM pro Job), nicht persistent.

Bug-Klasse als langfristige Antwort

Drei XFRM/ESP-LPEs in drei Wochen sind kein Zufall. Die Schicht ist offensichtlich unter aktiver Auditierung durch externe Forscher. Wer die esp-Module produktiv nicht braucht, sollte sie permanent in der Plattform-Baseline blacklisten — nicht erst CVE für CVE einzeln mitigieren. Bei Moselwal haben wir die Blacklist seit Dirty Frag als Default in unserem NixOS-/Ansible-Plattformprofil. Fragnesia hat dadurch für unsere Bestandskunden keinen Sofortaufwand erzeugt — nur den drop_caches-Step nachgeschoben.

Was wir bei Moselwal konkret getan haben

Mitigation war bereits aktiv (seit Dirty Frag)

Die modprobe-Blacklist auf esp4, esp6, rxrpc haben wir nach Dirty Frag (07.05.) in unser NixOS-Basis-Profil und unsere Ansible-Plattform-Rolle aufgenommen. Auf allen Bestandskunden-Hosts war die Blacklist also bereits seit 08.05. aktiv. Fragnesia wurde dadurch automatisch mit-mitigiert — ohne zusätzlichen Rollout am 13.05.

Page-Cache-Drop als zusätzlicher Schritt

Am 13.05. nach Disclosure haben wir auf allen Hosts einen drop_caches-Schritt nachgeschoben, um potenziell vergiftete Page-Cache-Inhalte aus dem Zeitfenster zwischen 07.05. und Mitigation-Rollout zu invalidieren. Operative Last: ein paar Sekunden höhere Disk-Read-Latency, kein Service-Impact.

Kernel-Update-Schedule

Sobald die Distributionen den erweiterten Fix (Stand 14.05.: „zusätzlicher Exploit-Pfad identifiziert“) in stable freigeben:

• CL9 + CL10: Update aus AlmaLinux-stable, Reboot innerhalb 48h nach Production-Promotion
• NixOS-Hosts (eigene Infra): Mainline-Update sobald in nixpkgs unstable, ggf. Backport in unsere Channel-Pinning-Branch
• KernelCare-Hosts: automatischer Livepatch-Update, kein Reboot

Forensik-Lite-Pass

Auf Hosts mit lokalen FE-Usern (Shared-Hosting-Stack) haben wir einen kurzen Audit-Pass durchgeführt: last -F | head -30, journalctl --since "2026-05-07" -p warning, plus rpm -V auf Privilegen-Binäries nach Page-Cache-Drop. Bisher keine Auffälligkeiten — die Mitigation hat vor dem Public-PoC gegriffen.

Plattform-Baseline-Update

Die modprobe-Blacklist bleibt permanent im Plattform-Profil, nicht nur als CVE-spezifische Reaktion. Wer kernel-mode IPsec braucht (das sind bei uns null Bestandskunden), bekommt ein dediziertes Hardened-Profil ohne Blacklist und mit eng kontrollierter Patch-Reaktion. Plus: wir haben unsere Falco-Regel-Sammlung um die setsockopt(espintcp)-Detection erweitert, als zweite Verteidigungslinie.

Fazit

Fragnesia ist die dritte Linux-Kernel-LPE in drei Wochen aus derselben Bug-Klasse. Wer die Dirty-Frag-Mitigation bereits ausgerollt hat, ist auch gegen Fragnesia geschützt — und muss nur einmal den Page-Cache droppen, um mögliche Rückstände aus dem Zeitfenster vor Dirty Frag zu entfernen. Wer noch nicht mitigiert hat, sollte das jetzt tun: drei Zeilen modprobe-Config, ein drop_caches, fertig. Auf typischen TYPO3-Hosts gibt es keinen Nebeneffekt, weil ESP-in-TCP dort nicht produktiv genutzt wird.

Strukturell ist Fragnesia ein Indikator, dass die XFRM/ESP-Schicht im Linux-Kernel unter aktiver externer Auditierung steht — statistisch wahrscheinlich kommen weitere CVEs. Wer die Module nicht braucht, sollte sie permanent blacklisten, nicht erst CVE für CVE einzeln reagieren. Bei Moselwal ist die Blacklist seit Dirty Frag fester Bestandteil unseres NixOS-/Ansible-Plattformprofils. Fragnesia hat dadurch für unsere Bestandskunden nur den drop_caches-Schritt erzeugt — nichts weiter.