Linux-Kernel CVE-2026-46300 (Fragnesia): Ein verlorenes Flag lässt IPsec in den Page Cache schreiben

TL;DR — 90 Sekunden

• Was: Beim Zusammenlegen von Socket-Puffern in skb_try_coalesce() verlor der Kernel die Markierung für fremde Speicherseiten. Der ESP-in-TCP-Empfangspfad hielt Seiten aus dem Page Cache deshalb für eigene und entschlüsselte direkt in sie hinein, was einem lokalen Nutzer Schreibzugriff auf jede lesbare Datei im Speicher verschafft.
• Schwere: CVSS 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). Ein öffentlicher Exploit existiert seit der Offenlegung am 13. Mai, seit dem 28. Oktober steht die Lücke in der CISA-KEV, und Dream Research hat Angriffe dokumentiert, die sie mit PHP2Shell kombinieren.
• Wen es trifft: Linux-Hosts mit Kerneln ohne den Fix vom Mai, auf denen ESP-in-TCP verfügbar ist und unprivilegierte Prozesse User Namespaces anlegen dürfen. Dazu zählen ungepatchte Kubernetes-Nodes auf Debian oder RHEL-Derivaten. Amazon Linux und Bottlerocket sind laut AWS nicht betroffen.
• Was zu tun ist: Den Kernel auf einen Stand mit den Fixes für CVE-2026-46300 und CVE-2026-43503 bringen und neu starten. Bis dahin die Module esp4 und esp6 sperren, sofern auf dem Host kein IPsec läuft.
• Was vorher geschützt hätte: Die Modulsperre aus dem Dirty-Frag-Fall, seccomp für jeden Pod, damit Workloads keine User Namespaces anlegen können, und allowPrivilegeEscalation: false. readOnlyRootFilesystem und Integritätsprüfungen auf der Platte helfen dagegen nicht.

Wie ein einzelnes Bit die Kopie verhindert

Der Netzwerkstack von Linux verwaltet Pakete in Strukturen namens sk_buff. Die Nutzdaten liegen dabei oft nicht in einem zusammenhängenden Puffer, sondern als Liste von Fragmenten, die auf einzelne Speicherseiten verweisen. Das spart Kopien. Schickt ein Programm eine Datei mit splice() über einen Socket, hängt der Kernel die Seiten aus dem Page Cache direkt als Fragmente an das Paket. Diese Seiten gehören aber weiterhin der Datei. Damit kein späterer Verarbeitungsschritt das vergisst, setzt TCP nach dem Spleißen laut Commit-Nachricht des Dirty-Frag-Fixes das Flag SKBFL_SHARED_FRAG. Es sagt jedem, der die Daten verändern will, dass er vorher eine private Kopie braucht.

Auf der anderen Seite steht IPsec. ESP entschlüsselt eingehende Pakete, und um Kopien zu sparen, kennt esp_input() einen Schnellpfad: Ist das Paket nicht geklont und hat keine frag_list, entschlüsselt ESP direkt in den vorhandenen Fragmenten, statt mit skb_cow_data() eine eigene Kopie anzulegen. ESP-in-TCP nach RFC 8229 verpackt ESP-Pakete zusätzlich in einen TCP-Strom, damit IPsec auch durch Netze kommt, die nur TCP durchlassen. Im Kernel übernimmt das ein Upper Layer Protocol namens espintcp, das ein Socket nachträglich einschalten kann.

Im Mai zeigte Dirty Frag (CVE-2026-43284), dass dieser Schnellpfad auch Fragmente aus gespleißten Pipe-Seiten traf. Der Fix f4c50a4034e6 setzte das Flag deshalb auch in den UDP-Pfaden und ließ ESP auf skb_cow_data() zurückfallen, sobald skb_has_shared_frag() anschlägt. Die Sicherheit hing danach an einer einzigen Annahme: Das Flag ist überall gesetzt, wo fremde Seiten in einem Paket stecken.

Genau hier lag der Fehler. skb_try_coalesce() legt im TCP-Empfangspfad aufeinanderfolgende Puffer zusammen und hängt dafür die Fragment-Deskriptoren des einen an den anderen. Die Markierung aus dem Feld flags der Quelle übernahm die Funktion dabei nicht. Aus einem Paket mit fremden Seiten wurde so eines, das wie ein gewöhnliches privates Paket aussah, und ESP nahm wieder den Schnellpfad. William Bowling von V12 Security veröffentlichte den Fehler am 13. Mai mit Exploit und Patch, ohne vorheriges Embargo. Der Fixes-Tag des Patches verweist ausdrücklich auf den Dirty-Frag-Fix. Fragnesia ist also genau die Stelle, an der dieser Fix nicht griff.

Warum daraus Root wird, erklärt die Kryptografie. AES-GCM entschlüsselt im Kern durch ein XOR mit einem Schlüsselstrom. Wer den Schlüssel der Sicherheitsassoziation selbst festlegt, kennt diesen Strom und kann damit gezielt Bytes in die fremde Seite schreiben. Laut V12 und Tenable zielt der öffentliche Exploit auf die im Page Cache liegende Kopie von /usr/bin/su. Die Datei auf der Platte bleibt unverändert, doch jeder Prozess, der su startet, bekommt die manipulierte Fassung aus dem Speicher, bis die Seite verdrängt wird oder der Rechner neu startet. Einen Wettlauf braucht es dafür nicht, der Schreibvorgang lässt sich beliebig wiederholen.

Bleibt die Frage, warum ein gewöhnlicher Nutzer überhaupt eine ESP-Sicherheitsassoziation anlegen darf. Das geschieht über Netlink mit dem Protokoll NETLINK_XFRM, und der Kernel verlangt dafür CAP_NET_ADMIN im jeweiligen Netzwerk-Namespace. Ein unprivilegierter Prozess bekommt diese Capability, indem er einen eigenen User Namespace und darin einen Netzwerk-Namespace anlegt. Das ist gewolltes Design, denn User Namespaces sollen Container ohne Root ermöglichen. Der Preis dafür ist, dass jeder lokale Nutzer große Teile des Netzwerkstacks erreicht, die früher nur Root ansprechen konnte. Fragnesia ist ein weiteres Beispiel aus einer langen Reihe solcher Lücken.

Was der Fix-Commit ändert

Der Fix f84eca581739 („net: skbuff: preserve shared-frag marker during coalescing“) besteht aus zwei Zeilen in net/core/skbuff.c. Nachdem skb_try_coalesce() die Fragmente der Quelle an das Ziel gehängt hat, übernimmt die Funktion jetzt das Bit SKBFL_SHARED_FRAG aus den flags der Quelle, sofern sie tatsächlich Fragmente übertragen hat. Den zweiten Weg der Funktion, der Daten in freien Platz am Ende des Ziels kopiert, lässt der Commit unverändert. Dort werden Bytes kopiert und keine Verweise auf fremde Seiten weitergereicht. Eric Dumazet hat den Patch geprüft, und die Fixes-Tags verweisen auf einen Commit von 2013 und auf den Dirty-Frag-Fix.

Aufschlussreicher als der Patch selbst ist, was zwei Tage später folgte. Der Commit 48f6a5356a33 („net: skbuff: propagate shared-frag marker through frag-transfer helpers“), heute als CVE-2026-43503 geführt, setzt das Bit auch in __pskb_copy_fclone() und skb_shift() und deckt weitere Helfer wie skb_gro_receive(), tcp_clone_payload() und skb_segment() ab. Das verrät die eigentliche Ursache. Die Garantie, dass fremde Seiten vor dem Schreiben kopiert werden, steckt nicht an einer Stelle, sondern in einem Bit, das jede Funktion korrekt weiterreichen muss, die Fragmente zwischen Puffern bewegt. Eine einzige vergessene Stelle genügt. Was ich daraus ableite: Solange diese Invariante über so viele Funktionen verteilt bleibt, ist mit weiteren Lücken derselben Klasse zu rechnen, und die Härtung sollte genau davon ausgehen.

Vom Webshell-Nutzer zu Root auf dem Host

Für Fragnesia muss ein Angreifer zuerst eigenen Code auf dem System ausführen, wobei die Rechte dieses Codes keine Rolle spielen. Dazu kommen ein Kernel ohne den Fix vom Mai, eine verfügbare ESP-in-TCP-Unterstützung und die Erlaubnis, User Namespaces anzulegen. Auf den meisten Distributionen ist das ab Werk der Fall: Unprivilegierte User Namespaces sind laut Tenable meist eingeschaltet, und die ESP-Module lädt der Kernel bei Bedarf selbst nach. Eine Ausnahme bilden Amazon Linux und Bottlerocket. Sie liefern das Modul espintcp laut AWS-Bulletin 2026-029 gar nicht aus und sind deshalb nicht betroffen.

Der Ablauf bleibt dabei vollständig lokal. Der Angreifer verschafft sich in eigenen Namespaces die nötige Capability, richtet eine ESP-Sicherheitsassoziation mit einem selbst gewählten Schlüssel ein und lässt Seiten einer lesbaren Datei über eine TCP-Verbindung in den ESP-Empfangspfad laufen. Die Entschlüsselung überschreibt dann Bytes dieser Datei im Page Cache. Startet anschließend jemand das veränderte setuid-Programm, läuft der eingeschleuste Code als Root. Dabei stürzt nichts ab, und auf der Platte bleibt keine Spur.

Dass es bei der Theorie nicht geblieben ist, zeigt ein Bericht von Dream Research vom 26. Oktober, den die Autoren am 29. Oktober aktualisiert haben. Danach kombinierte ein Angreifer einen selbst gebauten PHP2Shell-Exploit mit Fragnesia und verschaffte sich Root auf 25 Servern. 24 davon waren PAN-OS-Firewalls von Palo Alto Networks, der fünfundzwanzigste ein interner Management-Server, den er über einen Tunnel von einer bereits übernommenen Firewall aus erreichte. Die Ziele lagen in den USA, Japan, Taiwan und Südkorea, darunter ein Umfeld mit Bezug zur US-Regierung. Einen konkreten Akteur nennt Dream nicht, sieht aber mehrere Hinweise auf eine Operation mit China-Bezug, und Unit 42 führt die Aktivität als CL-UNK-1280.

Für die Härtung ist ein Detail aufschlussreich. Der Angreifer lief zunächst als unprivilegierter Nutzer nobody, zusätzlich durch SELinux eingeschränkt, und kam über die Kernel-Lücke trotzdem an Root. Dabei veränderte er laut Dream die PAM-Konfiguration von su mit einer Regel für pam_permit.so, die jede Anmeldung durchwinkt. Palo Alto Networks warnte am 29. Oktober vor aktiver Ausnutzung von PHP2Shell gegen erreichbare PAN-OS-Managementoberflächen. CISA hatte die Kernel-Lücke bereits am 28. Oktober in den KEV-Katalog aufgenommen und ausdrücklich auf die Verkettung mit CVE-2026-109618 und CVE-2026-109619 hingewiesen.

Für TYPO3- und PHP-Betreiber ist genau diese Kette der interessante Teil. PHP2Shell liefert Codeausführung als PHP-Nutzer, im Kubernetes-Fall also in einem Container. Fragnesia macht daraus Root auf dem Node, weil sich alle Container den Kernel des Hosts teilen. Wer PHP noch nicht auf die Oktober-Releases gebracht hat und zugleich Nodes mit ungepatchtem Kernel betreibt, hat damit beide Glieder der Kette im eigenen Cluster.

Wirklich betroffen sind also Hosts und Nodes mit Kerneln von Debian, RHEL-Derivaten oder eigenen Builds, die seit Mai kein Kernel-Update mit Neustart bekommen haben. Entwarnung gilt dagegen für EKS-Nodes mit Amazon Linux 2023 oder Bottlerocket. Eine dritte Gruppe wiegt sich in falscher Sicherheit: Wer im Mai nur den Kernel-Patch gegen Dirty Frag eingespielt hat, ist gegen Fragnesia laut Tenable nicht geschützt. Geschützt ist dagegen, wer damals zusätzlich die ESP-Module gesperrt hat.

Der öffentliche Exploit liegt seit dem 13. Mai bei V12 auf GitHub, Tenable hat ihn auf einem Standard-Kernel nachvollzogen. Seit dem 28. Oktober steht die Lücke im KEV-Katalog mit Frist zum 31. Oktober für US-Bundesbehörden. EPSS schätzte die Wahrscheinlichkeit einer Ausnutzung in den nächsten 30 Tagen am 1. November auf rund 16 Prozent, nachdem der Wert am 25. Oktober erstmals die Marke von 10 Prozent überschritten hatte.

Kernel-Updates und Status je Distribution

Upstream steckt der Fix in den Stable-Releases 7.0.10, 6.18.33, 6.12.91, 6.6.141, 6.1.174, 5.15.208 und 5.10.257. Debian hat ihn mit DSA-6306-1 für Bookworm (6.1.174-1), DSA-6295-1 für Trixie (6.12.90-1) und DLA-4606-1 für Bullseye (5.10.257-1) verteilt. Diese Pakete enthalten laut Debian-Tracker auch den Folgefix für CVE-2026-43503. RHEL und seine Derivate haben ebenfalls im Mai Kernel-Updates veröffentlicht, die genauen Paketstände nennen die jeweiligen Advisories. Entscheidend ist der Neustart, denn ein installiertes, aber nicht gebootetes Kernel-Paket schützt nicht.

Für Amazon Linux lohnt ein genauer Blick. AWS erklärt im Bulletin 2026-029, Amazon Linux und Bottlerocket lieferten das Modul espintcp nicht aus und seien daher nicht betroffen. Als zusätzliche Absicherung hat AWS die Korrektur im Netzwerkkern trotzdem verteilt. Laut ALAS-Datenbank ist CVE-2026-46300 für Amazon Linux 2 in kernel (ALAS2-2026-3307) sowie in den Extras kernel-5.4 (ALAS2KERNEL-5.4-2026-122), kernel-5.10 (ALAS2KERNEL-5.10-2026-119) und kernel-5.15 (ALAS2KERNEL-5.15-2026-103) behoben. Für Amazon Linux 2023 gilt das für kernel (ALAS2023-2026-1710), kernel6.12 (ALAS2023-2026-1708) und kernel6.18 (ALAS2023-2026-1709). Alle Advisories stammen vom 15. Mai und decken auch CVE-2026-43503 ab, Livepatches folgten am 25. Mai.

Wolfi liefert keinen Host-Kernel. Container auf Wolfi- oder Alpine-Images laufen auf dem Kernel des Nodes, ein neues Base-Image ändert an dieser Lücke also nichts. Das gilt für alle Container-Images, und deshalb melden Image-Scanner Fragnesia auch nicht sinnvoll. Den Kernel musst du auf Ebene der Nodes prüfen.

Drei Stolperfallen zeigen sich in der Praxis. Erstens ist uname -r bei Distributionskerneln mit Backports kein verlässlicher Indikator, maßgeblich ist die Paketversion im Vergleich mit dem Advisory. Zweitens steht der Neustart in Spannung zur Forensik, denn er löscht eine mögliche Manipulation im Page Cache und damit auch den Beweis. Bei Verdacht prüfst du also zuerst und startest danach neu, wie im Abschnitt zur Erkennung beschrieben. Drittens wirkt eine Modulsperre nur, wenn ESP als Modul gebaut ist. Ist es fest im Kernel einkompiliert, lässt sich nichts sperren, was modprobe -n -v esp4 schnell zeigt.

Härtung über den Kernel-Patch hinaus

Zuerst die Einordnung. Der Fehler sitzt im Kernel, nicht in einer Anwendung, und er setzt voraus, dass der Angreifer bereits Code auf dem System ausführt. Wirksam ist deshalb alles, was ihm den Weg zum verwundbaren Pfad versperrt, also Module, Namespaces und Syscalls, und alles, was den Gewinn aus dem Schreibzugriff schmälert. Wer keine setuid-Rechte nutzen kann und keine Dateien sieht, die ein privilegierter Prozess liest, hat mit dem Schreibzugriff wenig gewonnen. Maßnahmen, die nur Dateisystem oder Netzwerk schützen, greifen dagegen ins Leere, weil der Schreibvorgang an allen Dateirechten vorbei im Speicher passiert.

ESP-Module sperren, wo kein IPsec läuft

Der verwundbare Pfad ist nur erreichbar, wenn ESP geladen ist. Eine Datei in /etc/modprobe.d/ mit install esp4 /bin/false und install esp6 /bin/false verhindert das Nachladen. TuxCare und Tenable nennen zusätzlich rxrpc, das für Fragnesia selbst keine Rolle spielt. Bereits geladene Module entfernst du mit rmmod. Diese Sperre war schon im Mai die empfohlene Mitigation für Dirty Frag, und wer sie damals umgesetzt hat, war gegen Fragnesia von Anfang an geschützt. Darin liegt ihr eigentlicher Wert: Sie schließt eine ganze Klasse von Fehlern im ESP-Code, ohne dass jemand die nächste Lücke kennen muss.

Für Kubernetes ist ein Punkt wichtig. Das Nachladen eines Moduls erledigt immer der Kernel des Hosts, auch wenn ein Prozess in einem Container es auslöst. Eine Sperre auf Node-Ebene schützt deshalb alle Pods, sie muss aber über das Node-Image, ein Konfigurationsmanagement oder ein DaemonSet auf jeden Node gelangen. Die Grenze ist IPsec selbst: strongSwan und Libreswan funktionieren danach nicht mehr, WireGuard bleibt unberührt. Prüfe vorher, ob dein CNI Verschlüsselung über IPsec nutzt, wie es Cilium und Calico als Option anbieten. In diesem Fall bricht die Sperre die Verschlüsselung zwischen den Nodes. Wer auf einem Host gar keine Module mehr nachladen will, kann nach dem Booten kernel.modules_disabled=1 setzen. Laut Kernel-Doku lässt sich dieser Schalter bis zum nächsten Neustart nicht zurücknehmen, er eignet sich also nur für Nodes mit fest definiertem Modulbestand.

User Namespaces für Anwendungs-Pods verbieten

Ohne eigenen User Namespace bekommt ein unprivilegierter Prozess kein CAP_NET_ADMIN und kann keine ESP-Sicherheitsassoziation anlegen. Das wirksamste Mittel auf Pod-Ebene ist deshalb seccomp, und dabei hilft schon das Standardprofil der Runtime. Im Quelltext des Standardprofils von containerd stehen unshare, setns und clone3 nur Prozessen mit CAP_SYS_ADMIN offen, und clone lehnt das Profil ab, sobald Flags für neue Namespaces wie CLONE_NEWUSER oder CLONE_NEWNET gesetzt sind. clone3 übergibt seine Flags in einer Struktur im Speicher, die seccomp nicht auslesen kann. Das Profil beantwortet den Aufruf deshalb mit ENOSYS, worauf die C-Bibliothek auf das filterbare clone ausweicht. Das Profil von Docker ist im aktuellen Stand gleich aufgebaut, auch wenn die Tabelle in der Docker-Dokumentation noch eine Ausnahme für unshare --user nennt. Ob das auf deinen Nodes greift, prüfst du am einfachsten in einem Test-Pod mit unshare -U true, das unter RuntimeDefault scheitern sollte. Die Falle liegt im Standard von Kubernetes, denn ohne Angabe laufen Pods dort mit Unconfined, also ganz ohne seccomp. Abhilfe schaffen seccompDefault: true in der Kubelet-Konfiguration und der Pod Security Standard „restricted“, der ein seccomp-Profil vorschreibt.

Mit einem eigenen Profil vom Typ Localhost lässt sich zusätzlich socket() mit der Familie AF_NETLINK und dem Protokoll NETLINK_XFRM sperren, denn seccomp kann einfache Argumente eines Syscalls vergleichen. Ein PHP-Prozess hat keinen Grund, IPsec zu konfigurieren. Der Betriebsaufwand liegt in der Verteilung der Profile auf die Nodes, wofür sich der Security Profiles Operator anbietet, und in einem Test, ob Werkzeuge im Image wider Erwarten Namespaces brauchen. Auf Host-Ebene gibt es mit user.max_user_namespaces=0 die gröbere Variante, die laut TuxCare aber rootlose Container, Flatpak und Browser-Sandboxes bricht. Laut Kernel-Doku gilt die Grenze für jeden Nutzer im jeweiligen User Namespace, also auch für Root. Ich leite daraus ab, dass dann auch die Container-Runtime für Pods mit hostUsers: false keinen User Namespace mehr anlegen kann. Beide Maßnahmen schließen sich damit aus, und für Kubernetes-Nodes ist das seccomp-Profil der bessere Weg.

Kein setuid-Gewinn im Container

Der öffentliche Exploit verändert su und braucht danach einen Start dieses setuid-Programms. Setzt ein Container allowPrivilegeEscalation: false, aktiviert die Runtime für seine Prozesse no_new_privs. Laut Kernel-Doku ignoriert execve() dann setuid- und setgid-Bits, das veränderte su läuft also mit den Rechten des Aufrufers. Zusammen mit runAsNonRoot: true und capabilities: drop: ["ALL"] ist das der Kern des Pod Security Standard „restricted“. Im Container gibt es dann keinen Prozess, der eine manipulierte Datei mit höheren Rechten ausführt.

Die Grenze dieser Maßnahme liegt in der Natur des Fehlers, und hier wird es subtil. Der Schreibzugriff trifft den Page Cache einer Datei, also jede Kopie, die das System von dieser Datei im Speicher hält. Was ich daraus ableite: Teilen sich mehrere Container auf einem Node dieselbe Image-Schicht, teilen sie sich auch die Seiten im Page Cache, und ein Angreifer in einem harmlosen Pod könnte eine Datei verändern, die ein privilegierter Container aus demselben Base-Image ausführt. Dasselbe gilt für hostPath-Volumes, die ein Pod lesen darf. Privilegierte DaemonSets sollten deshalb nicht auf demselben Base-Image laufen wie die Anwendungs-Pods, und hostPath gehört in Mandanten-Namespaces verboten, was der Pod Security Standard „baseline“ bereits durchsetzt.

Pod-User-Namespaces mit hostUsers: false

Kubernetes kann Pods mit hostUsers: false in einem eigenen User Namespace starten. Root im Container entspricht dann einem unprivilegierten Nutzer auf dem Host. Gelingt einem Angreifer der Weg über ein manipuliertes setuid-Programm im Container, landet er laut dieser Logik nur bei einem Root ohne Rechte außerhalb des Pods. Das ist meine Ableitung aus dem Modell der User Namespaces, nicht eine Aussage der Fragnesia-Analysen. Den Schreibzugriff selbst verhindert die Option nicht, er hängt am Kernel und nicht an der UID. Deshalb ergänzt sie das seccomp-Profil, ersetzt es aber nicht. Voraussetzung sind ein aktueller Kernel mit ID-mapped Mounts und eine Container-Runtime, die das Feature unterstützt.

Den Einstieg erschweren

Fragnesia ist eine lokale Lücke, und der Angreifer muss zuerst eigenen Code ausführen. Im beobachteten Angriff lieferte PHP2Shell diesen Einstieg. Ein minimales Image ohne Shell und Compiler und eine PHP-Konfiguration, die exec(), proc_open() und verwandte Funktionen über disable_functions sperrt und FFI nicht freigibt, machen es schwerer, aus einer PHP-Lücke heraus ein natives Programm zu starten. Verhindern lässt sich das so nicht vollständig, aber jede zusätzliche Hürde zwischen Webshell und Kernel-Exploit kostet den Angreifer Zeit und erzeugt Spuren.

Was hier nicht hilft

Einige Standardmaßnahmen bleiben richtig, laufen gegen diesen Mechanismus aber ins Leere. readOnlyRootFilesystem schützt die Platte, Fragnesia schreibt aber in den Speicher, und das Ziel su ist ohnehin schreibgeschützt. Aus demselben Grund sehen Integritätsprüfungen wie AIDE und Image-Signaturen nichts, denn die Datei auf der Platte bleibt unverändert. Entzogene Capabilities allein helfen nicht, weil ein neuer User Namespace dem Prozess darin wieder alle Capabilities gibt. NetworkPolicies und Egress-Sperren bleiben wirkungslos, weil der gesamte Angriff lokal abläuft. Auch SELinux allein hat im beobachteten Angriff nicht gereicht, denn laut Dream lief der Angreifer als eingeschränkter Nutzer und kam trotzdem an Root. Und ein reiner Patch gegen Dirty Frag schützt nicht, weil er sich auf genau das Flag verlässt, das Fragnesia verliert.

Mehr zu Pod Security, seccomp-Profilen und Node-Härtung findest du in der Serie TYPO3 auf Kubernetes unter IT-Grundschutz.

Erkennung und Prüfung

Ob ein Host betroffen ist, klärst du in drei Schritten. Zuerst vergleichst du die installierte und gebootete Kernel-Paketversion mit dem Advisory deiner Distribution. Danach prüfst du mit lsmod, ob esp4, esp6 oder espintcp geladen sind, und mit modprobe -n -v, ob sie sich laden ließen. Zuletzt zeigt sysctl user.max_user_namespaces, ob unprivilegierte Prozesse überhaupt User Namespaces anlegen dürfen. Für Kubernetes ergänzt du die Frage, welche Pods ohne allowPrivilegeEscalation: false und ohne seccomp-Profil laufen.

Schwieriger ist die Frage, ob jemand die Lücke bereits genutzt hat, denn die Manipulation lebt nur im Speicher. Ein belegter Indikator aus der Kampagne ist eine Datei /etc/pam.d/su, die pam_permit.so enthält. Corgea empfiehlt, den Inhalt verdächtiger Dateien einmal normal und einmal mit O_DIRECT an der Platte vorbei zu lesen und die Ergebnisse zu vergleichen, sowie rpm -Va oder debsums -s laufen zu lassen. Weichen die gelesenen Inhalte von der Platte ab, wurde der Page Cache verändert. Im Verhalten fallen laut Corgea neu angelegte User- und Netzwerk-Namespaces in Workern oder Build-Jobs auf, XFRM-Netlink-Aktivität von Prozessen ohne IPsec-Aufgabe und das Laden von ESP-Modulen auf Hosts, die kein IPsec betreiben.

Bei einem Verdacht gilt eine klare Reihenfolge. Sichere zuerst die Beweise, solange der Page Cache noch die Manipulation enthält, denn ein Neustart oder ein Leeren des Caches entfernt Hintertür und Spur zugleich. Danach sperrst du die Module oder spielst den Kernel ein und startest neu. Einen bestätigten Fall behandelst du als vollständige Kompromittierung des Hosts. Auf einem Kubernetes-Node heißt das, die Zugangsdaten des Kubelets und alle Secrets und ServiceAccount-Tokens der Pods auf diesem Node als abgeflossen zu betrachten und zu rotieren.

Betreiberempfehlung

Akut handeln solltest du, wenn Hosts oder Kubernetes-Nodes mit einem Kernel ohne den Fix vom Mai laufen und dort Code von Dritten ausgeführt wird, ob als PHP-Anwendung, CI-Job oder Mandanten-Workload. Das gilt besonders, wenn PHP noch nicht auf den Oktober-Releases gegen PHP2Shell steht. Sperre dann sofort die ESP-Module, sofern kein IPsec gebraucht wird, und plane Kernel-Update und Neustart für die nächsten Tage, nicht für das nächste Quartal.

Beobachten genügt, wenn deine Nodes auf Amazon Linux oder Bottlerocket laufen oder wenn der Kernel nachweislich gepatcht und gebootet ist. Das seccomp-Profil gegen User Namespaces und allowPrivilegeEscalation: false lohnen sich trotzdem, denn sie entschärfen die nächste Lücke dieser Klasse, bevor es einen Patch gibt.

Unabhängig vom Einzelfall gilt, was ich bei jeder Lücke sage: Patches und Updates gehören automatisiert, und beim Kernel betrifft das die Node-Images. Schlagen Renovate oder Dependabot neue AMI-Versionen, Node-Images und Base-Images selbstständig als Merge Request vor und rollt die Pipeline die Nodes zuerst in Staging neu aus, ist ein Kernel-Fix wie dieser eine Sache von Stunden statt Wochen. Fragnesia zeigt, was sonst passiert: Der Fix lag seit Mai bereit, bekannt wurden die Angriffe in freier Wildbahn im Oktober, und dazwischen lagen fünf Monate, in denen jedes vergessene Update ein offenes Fenster blieb. Auf selbst betriebenen Debian-Nodes übernimmt diesen Teil ein automatisches Paket-Update zusammen mit einem Dienst wie kured, der die Nodes nacheinander geordnet neu startet. Eine Karenzzeit für Routine-Updates schützt dabei vor kompromittierten Releases, Sicherheitsupdates nimmst du davon aus. Bricht ein neuer Kernel etwas, etwa die IPsec-Verschlüsselung des CNI, fällt das im Test auf und nicht in Produktion. Wer Nodes dagegen von Hand aktualisiert, hat in der Urlaubszeit schnell Wochen ohne Patch und danach ein großes Sammel-Update, bei dem niemand mehr weiß, welche Änderung was ausgelöst hat.

Fazit

Fragnesia ist im Grunde der Fehler von Dirty Frag an einer anderen Stelle. Dirty Frag wurde behoben, indem ESP einem Flag vertraut, und Fragnesia fand eine Funktion, die dieses Flag nicht weitergab. Zwei Tage später folgte mit CVE-2026-43503 die nächste Gruppe solcher Funktionen. Die übertragbare Lehre: Wenn eine Sicherheitsgarantie davon abhängt, dass viele Codepfade eine Markierung korrekt weiterreichen, ist der einzelne Patch nur so gut wie die nächste vergessene Stelle. Härtung, die den ganzen Pfad unerreichbar macht, hält dagegen auch bei der nächsten Variante. Die Modulsperre aus dem Mai hat das bewiesen, und ein seccomp-Profil gegen User Namespaces leistet dasselbe für alle Kernel-Lücken, die ein Angreifer nur über einen eigenen User Namespace erreicht.

Quellen

• Linux Fix-Commit f84eca5 (net: skbuff: preserve shared-frag marker during coalescing)
• Linux Dirty-Frag-Fix f4c50a4 (xfrm: esp: avoid in-place decrypt on shared skb frags)
• Debian Security Tracker: CVE-2026-46300
• Debian Security Tracker: CVE-2026-43503
• Amazon Linux Security Center: CVE-2026-46300
• Amazon Linux Security Center: CVE-2026-43503
• AWS Security Bulletin 2026-029-AWS (Fragnesia)
• AWS Security Bulletin 2026-030-AWS
• Tenable: Fragnesia FAQ
• TuxCare: Fragnesia (CVE-2026-46300)
• Dream Research: Chained PHP2Shell exploit roots 25 servers
• Red Hat: CVE-2026-46300
• isMalicious: CVE-2026-46300 (EPSS)
• Linux Kernel Docs: sysctl user (max_user_namespaces)
• HOL: Fragnesia, CISA KEV und die PHP2Shell-Kampagne
• The Hacker News: PHP2Shell gegen PAN-OS-Managementoberflächen
• Rescana: Fragnesia in der CISA KEV
• Corgea: Fragnesia, Erkennung und Reaktion
• lilting.ch: Fragnesia und Container-Nodes
• viry.cz: CVE-2026-46300 (EPSS, KEV-Status)
• Docker Docs: Seccomp security profiles
• Linux Kernel Docs: No New Privileges Flag
• Linux Kernel Docs: sysctl kernel (modules_disabled)
• Kubernetes Docs: Pod Security Standards
• Kubernetes Docs: User Namespaces
• RFC 8229: TCP Encapsulation of IKE and IPsec Packets