Security 17.05.2026 Aktualisiert: 18.05.2026

Fragnesia CVE-2026-46300: Linux prüfen, mitigieren und patchen

Fragnesia betrifft Linux-Kernel, Plesk-, Proxmox- und Container-Hosts. Patchstände, Angriffsweg, Mitigation und Reboot-Prüfung.

Stand: 18.05.2026, 15:52 Uhr CEST. Fragnesia ist ein eigener Kernel-Bug, nicht nur ein anderer Name für Dirty Frag. Die Mitigation überschneidet sich. Die Kernel-Patches decken aber nicht automatisch beide Bugs ab. Bei Rocky Linux reicht ein Dirty-Frag-Hotfix weiterhin nicht als Entwarnung. Für Proxmox VE gibt es inzwischen ein eigenes Security Advisory mit Fragnesia-Fixständen. Entscheidend bleibt, ob dein laufender Kernel den Fragnesia-Fix für CVE-2026-46300 enthält oder ob die betroffenen ESP/XFRM-Pfade wirksam blockiert sind.

Kurzfassung

Worum es geht: Fragnesia, CVE-2026-46300, ist eine lokale Rechteausweitung im Linux-Kernel. Ein unprivilegierter lokaler Prozess kann unter passenden Bedingungen Root-Rechte bekommen.
Remote allein ausnutzbar: Nein. Der Angreifer braucht lokale Code-Ausführung, zum Beispiel einen Shell-Account, eine kompromittierte Webanwendung, einen CI-Job, Plugin-Code oder Code in einem Container.
Warum es trotzdem kritisch ist: Der öffentliche PoC ist zuverlässig genug, um aus einem begrenzten lokalen Einstieg Root zu machen. Das ist vor allem auf Shared-Hosting-, Plesk-, Proxmox-LXC-, Kubernetes-, Docker- und CI-Systemen relevant.
Nicht dasselbe wie Dirty Frag: Fragnesia sitzt im selben XFRM-/ESP-Umfeld, hat aber einen eigenen Patch. Ein Kernel, der nur Dirty Frag gefixt hat, ist deshalb nicht automatisch gegen Fragnesia gefixt.
Proxmox-Stand: Proxmox hat PSA-2026-00020-1 veröffentlicht. Gefixt sind unter anderem proxmox-kernel-7.0.2-3-pve, 6.17.13-8-pve, 6.14.11-9-pve, 6.8.12-24-pve und 6.14.11-9-bpo12-pve oder neuer. 7.0.2-2-pve war im Forum noch erfolgreich ausnutzbar.
Mitigation überschneidet sich: Wer die Dirty-Frag-Mitigation mit esp4, esp6 und rxrpc bereits konsequent aktiv hat, ist gegen den bekannten Fragnesia-Pfad praktisch mit abgedeckt. Entfernen solltest du diese Blockade erst, wenn Kernel-Fixes für Dirty Frag und Fragnesia aktiv sind.
Saubere Lösung: Vendor-Kernel aktualisieren, anschließend rebooten oder einen passenden Livepatch nachweisen. Danach prüfen, ob der laufende Kernel wirklich der gefixte Kernel ist.
Zwischenlösung: esp4, esp6 und im kombinierten Dirty-Frag-Kontext auch rxrpc blockieren. espintcp gehört in die Prüfung, weil der bekannte Fragnesia-PoC darüber läuft. Das kann IPsec, strongSwan, Libreswan, AFS oder Spezial-Setups brechen.
Nicht machen: Den öffentlichen PoC nicht auf Produktivsystemen laufen lassen. Er verändert Page-Cache-Seiten sensibler Dateien wie /usr/bin/su; nach einem Test oder Verdacht muss der Cache bereinigt oder der Host rebootet werden.

Was ist Fragnesia?

Fragnesia ist eine lokale Kernel-Lücke in der XFRM-/ESP-in-TCP-Nähe des Linux-Netzwerkstacks. Sie gehört zur gleichen größeren Fehlerklasse wie Dirty Pipe, Copy Fail und Dirty Frag: Kernel-Code schreibt auf Speicherseiten, die aus Sicht des Userspace nur gelesen werden dürfen.

Der unangenehme Teil ist wieder der Page Cache. Linux hält gelesene Dateiinhalte im RAM, damit spätere Zugriffe schneller sind. Wenn ein Angreifer eine Page-Cache-Seite einer eigentlich schreibgeschützten Datei manipulieren kann, muss die Datei auf dem Storage nicht verändert werden. Für Hash-Prüfungen kann die Datei sauber aussehen, während Prozesse im selben Moment die manipulierte RAM-Kopie lesen.

Der öffentliche Fragnesia-PoC zielt auf /usr/bin/su. Er schreibt nicht dauerhaft das Binary auf der Platte um, sondern verändert die gecachte Kopie im RAM. Wird su danach ausgeführt, läuft der manipulierte Inhalt aus dem Page Cache. Genau daraus entsteht die Root-Shell.

Fragnesia wurde am 13.05.2026 durch William Bowling vom V12-Team veröffentlicht. Ein Proof of Concept ist öffentlich. Mehrere Distributionen haben Advisories oder Mitigationen veröffentlicht, aber der Patchstand ist je nach Vendor sehr unterschiedlich.

Beim Schweregrad ist die Datenlage etwas unschön: Viele öffentliche Tracker nennen CVSS 3.1 mit 7.8, SUSE bewertet CVE-2026-46300 mit CVSS 3.1 8.8 und CVSS 4.0 8.6. NVD war zum geprüften Stand noch kein guter Anker, weil der Eintrag dort noch nicht sauber befüllt war. Für Change- und Compliance-Tickets würde ich deshalb den Score des eigenen Vendors dokumentieren und zusätzlich notieren, dass ein öffentlicher PoC existiert.

Wie funktioniert die Lücke technisch?

Die kurze Version: Der Kernel vergisst bei bestimmten Socket-Buffer-Operationen, dass ein Fragment auf gemeinsam genutzte, dateigestützte Speicherseiten zeigt. Danach behandelt der ESP-in-TCP-Pfad diese Seiten so, als wären sie normale Paketdaten, und entschlüsselt in place. Aus Sicht des Netzwerkcodes ist das ein Paketfragment. Praktisch ist es aber eine Page-Cache-Seite einer Datei.

Der Kernfehler liegt in der skbuff-Logik. Beim Zusammenführen oder Kopieren von Fragmenten wurde die Markierung für “shared frag” nicht sauber weitergegeben. Genau diese Markierung ist wichtig, weil sie dem Kernel sagt: Hier liegt kein beliebig beschreibbarer Paketpuffer, sondern ein extern referenzierter Speicherbereich, etwa eine über splice() eingebrachte Page-Cache-Seite.

Der Angriff nutzt grob diesen Ablauf:

Ein lokaler Prozess bereitet eine Netzwerk-Namespace-Umgebung und XFRM-/ESP-Zustände vor.
Daten einer lesbaren Zieldatei werden über splice() in einen TCP-Pfad gebracht.
Der Socket wechselt in den ESP-in-TCP-ULP-Modus.
Der Kernel verarbeitet die bereits im Socket-Buffer liegenden Dateiseiten als ESP-Ciphertext.
Die AES-GCM-Verarbeitung schreibt direkt in die gecachte Dateiseite.
Byte für Byte entsteht eine kontrollierte Veränderung im Page Cache.
Ein späterer Programmstart nutzt die manipulierte RAM-Kopie.

Das ist bewusst keine Exploit-Anleitung. Für den Betrieb reichen die wichtigen Punkte: Fragnesia braucht lokale Code-Ausführung, nutzt keinen normalen Dateischreibzugriff, braucht keine Race Condition und kann kleine, kontrollierte Writes in den Page Cache erzeugen.

Upstream-Fix und Kernelbereich

Für selbst gebaute Kernel, Gentoo-Systeme oder eigene Appliance-Kernel ist der Vendor-Tracker nicht genug. Dann musst du den Upstream-Stand prüfen.

Der veröffentlichte Fix begann mit dem Patch net: skbuff: preserve shared-frag marker during coalescing. In der Diskussion wurde daraus ein breiterer Fix für mehrere Frag-Transfer-Helfer, unter anderem __pskb_copy_fclone(), skb_try_coalesce() und skb_shift(). Genau diesen Punkt solltest du bei Custom-Kerneln suchen: Die SKBFL_SHARED_FRAG-Markierung muss beim Transfer von paged fragments erhalten bleiben.

Der initiale Patch nennt als Fixes-Kontext unter anderem:

Commit / Bereich	Bedeutung
`cef401de7be8`	Älterer Netzwerk-/Checksum-Kontext, in dem die gemeinsame Frag-Markierung relevant wird.
`f4c50a4034e6`	Dirty-Frag-Fix für `xfrm: esp`, der Fragnesia nicht automatisch mit schließt.
`CONFIG_INET_ESPINTCP`	ESP-in-TCP-Unterstützung, in Linux laut LKDDb ab 5.6 vorhanden, wenn Kernel und Distribution sie aktivieren.

Eine einfache Upstream-Regel ist deshalb: Wenn dein Kernel ESP/XFRM und ESP-in-TCP enthält, aber keinen Fix für die shared-frag-Propagation in skbuff hat, behandelst du ihn als betroffen. Bei Fedora tauchte der erste Fragnesia-Fix in den 7.0.6-Kernelupdates auf; 7.0.7 und 7.0.8 zogen vollständigere Varianten nach. Bei LTS- und Vendor-Kerneln ist eine nackte Versionsnummer weniger belastbar als der Nachweis des konkreten Backports.

Was braucht ein Angreifer?

Fragnesia ist keine unauthentifizierte Remote-Code-Execution. Ein zufälliger Internetnutzer bekommt nicht nur durch einen offenen TCP-Port Root auf deinem Server. Der Angreifer braucht bereits eine Möglichkeit, Code auf dem System auszuführen.

In der Praxis ist das trotzdem kein exotisches Szenario:

kompromittierte WordPress-, TYPO3-, Shopware-, Laravel- oder Node.js-Anwendung
Shell-Zugang eines Kunden, Entwicklers oder Dienstleisters
Plesk- oder Shared-Hosting-System mit getrennten Systembenutzern
GitLab Runner, GitHub Actions Runner, Jenkins-Agent oder anderer CI-Worker
Docker-, Kubernetes- oder LXC-Workload mit nicht vollständig vertrauenswürdigem Code
Plugin-Code, Build-Scripts, Cronjobs oder Deployment-Hooks
gestohlene SSH-Zugangsdaten eines unprivilegierten Users

Auf Ubuntu spielt AppArmor zusätzlich hinein. Canonical und V12 weisen darauf hin, dass Einschränkungen für unprivileged user namespaces den bekannten PoC erschweren können. Das ist aber keine saubere Entwarnung. Es reduziert einen Weg, ersetzt aber keinen Kernel-Fix, und andere Distributionen oder Workload-Profile haben andere Defaults.

Bei Containern gilt die alte Regel: Das Image ist nicht der Kernel. Ein Debian-, Alpine- oder Ubuntu-Container nutzt den Host-Kernel. Wenn der Host-Kernel verwundbar ist und die Container-Policy die nötigen Kernelpfade zulässt, ist das ein Host-Thema, kein Image-Thema.

Wer ist betroffen?

Betroffen sind Linux-Systeme, auf denen der verwundbare XFRM-/ESP-in-TCP-Pfad vorhanden und für lokale Prozesse erreichbar ist. Eine reine Kernel-Hauptversion reicht für die Bewertung nicht, weil Distributionen Fixes zurückportieren und Kernel-Konfigurationen unterscheiden.

Umgebung	Einschätzung	Worauf prüfen
Debian	Debian listet Bullseye, Bookworm, Trixie, Forky und Sid im Security Tracker zum geprüften Stand als vulnerable/unfixed.	Debian Security Tracker und laufenden Kernel prüfen. Dirty-Frag-Fixes nicht als Fragnesia-Fix behandeln.
Ubuntu	Canonical bewertet Fragnesia als High und führt alle Ubuntu-Releases in der Mitigation als betroffen. Die CVE-Seite stand überwiegend auf “Needs evaluation”.	Ubuntu-CVE-Seite pro Kernel-Flavour prüfen. Mitigation beibehalten, bis ein passender Kernel-Fix installiert und aktiv ist.
RHEL, CentOS Stream, OpenShift	Red Hat führt CVE-2026-46300 im Dirty-Frag-Bulletin mit. Betroffen sind laut Red Hat RHEL 8, 9, 10 und OpenShift 4; Status zum geprüften Stand: ongoing.	Red-Hat-Bulletin, Errata und laufenden Kernel prüfen. Red Hat validiert bestehende Mitigationen für Fragnesia.
AlmaLinux	AlmaLinux hat gepatchte Kernel für AL8, AL9 und AL10 in die Production-Repositories gebracht.	Mindestens `kernel-4.18.0-553.124.3.el8_10`, `kernel-5.14.0-611.54.5.el9_7` oder `kernel-6.12.0-124.56.3.el10_1`, danach Reboot.
Rocky Linux	Rocky ist praktisch relevant, weil die Dirty-Frag-Security-Repo-Kernel Fragnesia nicht automatisch abdecken. Im Rocky-Forum wurde am 14.05. ausdrücklich festgehalten, dass Fragnesia einen zusätzlichen Fix braucht; am 18.05. gab es dort noch Nachfrage nach einem Update.	Mitigation beibehalten, Security-Repo und Errata prüfen. Nicht nur den Dirty-Frag-Hotfix installieren und die Mitigation entfernen.
CloudLinux	CL7 ist laut CloudLinux nicht betroffen. CL7h, CL8, CL9 und CL10 sind betroffen und haben Kernel- oder KernelCare-Pfade.	CL7h/CL8: `kernel-4.18.0-553.124.3.lve...` oder neuer. CL9/CL10 folgen AlmaLinux-Zielständen. KernelCare separat nachweisen.
Amazon Linux / Bottlerocket	AWS stuft Amazon Linux und Bottlerocket für Fragnesia als nicht betroffen ein, weil der PoC-Vektor über `espintcp` dort nicht bereitgestellt wird. AWS will trotzdem härtende Netzwerk-Fixes einpflegen.	AWS Bulletin 2026-029/030 prüfen. Nicht mit Dirty Frag verwechseln: Dort waren Amazon-Linux-Kernel betroffen.
Oracle Linux	Zum geprüften Stand war kein eindeutiger Oracle-CVE-Eintrag für CVE-2026-46300 sichtbar. KernelCare nennt Livepatch-IDs für Oracle Linux 8/9 und UEK 7, das ersetzt aber kein Oracle-Erratum.	`uname -r`, `rpm -q kernel kernel-uek`, Oracle CVE/ELSA und Ksplice/KernelCare-Status getrennt prüfen.
Fedora	Fedora 44 enthält Fragnesia-Fixes ab `kernel-7.0.6-200.fc44`; `7.0.7` und `7.0.8` enthalten weitere bzw. vollständigere skbuff-Fixes.	Auf aktuellen Fedora-Kernel aktualisieren, rebooten und nicht bei `7.0.4` stehen bleiben.
SUSE / openSUSE / SUSE Linux Micro	SUSE führt je nach Produkt “Released”, “In progress”, “Affected” und “Not affected”. SUSE Linux Micro 6.0/6.1 steht auf Released; viele SLE-15/16-Varianten waren noch in progress oder affected.	Produktgenaue SUSE-CVE-Seite prüfen. Paketnamen und Kernel-Flavour sind entscheidend.
Proxmox VE	Proxmox führt Fragnesia in PSA-2026-00020-1. Der frühere Forumstest mit PVE 9.1.11 und `7.0.2-2-pve` bleibt wichtig, weil genau dieser Dirty-Frag-Fixstand noch kein Fragnesia-Fix war.	Gefixt sind `7.0.2-3-pve`, `6.17.13-8-pve`, `6.14.11-9-pve`, `6.8.12-24-pve` und `6.14.11-9-bpo12-pve` oder neuer. Installierten und laufenden Kernel prüfen.
Plesk-Server	Plesk selbst ist nicht der Bug. Entscheidend ist der Kernel des darunterliegenden Betriebssystems.	OS-Vendor-Fix, KernelCare falls vorhanden, Reboot-Status und Modul-Mitigation prüfen.
Docker, Kubernetes, CI-Runner	Besonders relevant, wenn fremder Code läuft. Container teilen sich den Host-Kernel.	Node-Kernel patchen, seccomp/AppArmor/SELinux prüfen, CI-Runner kontrolliert drainen oder pausieren.
Single-Tenant-Server ohne fremde Shells	Geringeres Risiko, aber nicht “nicht betroffen”. Eine kompromittierte Anwendung ist lokaler Code.	Mit normalem Wartungsfenster patchen, bei öffentlichem PoC nicht unnötig warten.

Patchstände nach Distribution

Die Tabelle ist kein Ersatz für den jeweiligen Vendor-Tracker. Sie zeigt den geprüften Stand und die Versionen, die für typische Serverumgebungen relevant sind.

Distribution / Plattform	Stand zum geprüften Zeitpunkt
Debian Bullseye, Bookworm, Trixie, Forky, Sid	Debian Security Tracker: `linux` unfixed, die gelisteten Stände `5.10.223-1`, `5.10.251-5`, `6.1.170-3`, `6.1.172-1`, `6.12.86-1`, `6.12.88-1`, `7.0.4-1`, `7.0.7-1` waren dort als vulnerable markiert.
Ubuntu 14.04 ESM bis 26.04 LTS	Canonical-Mitigation: alle gelisteten Releases betroffen, Fix kommt über Kernel-Image-Pakete, bis dahin Modul-Mitigation. Ubuntu-CVE-Seite: viele Kernel-Flavours “Needs evaluation”.
RHEL 8/9/10 und OpenShift 4	Red Hat RHSB-2026-003: affected, Important, ongoing. CVE-2026-43500 betrifft Red Hat laut Red Hat nicht, CVE-2026-43284 und CVE-2026-46300 aber schon.
AlmaLinux 8	Production-Fix ab `kernel-4.18.0-553.124.3.el8_10`.
AlmaLinux 9	Production-Fix ab `kernel-5.14.0-611.54.5.el9_7`.
AlmaLinux 10	Production-Fix ab `kernel-6.12.0-124.56.3.el10_1`.
AlmaLinux Kitten 10	AlmaLinux nannte `kernel-6.12.0-227.el10` als geplanten Zielstand, der Build war in der Advisory-Historie noch separat erwähnt.
CloudLinux 7	Laut CloudLinux nicht betroffen.
CloudLinux 7h	Fixziel `kernel-4.18.0-553.124.3.lve.el7h` oder neuer.
CloudLinux 8	Fixziel `kernel-4.18.0-553.124.3.lve.el8` oder neuer.
CloudLinux 9	Fixziel wie AlmaLinux 9: `kernel-5.14.0-611.54.5.el9_7` oder neuer.
CloudLinux 10	Fixziel wie AlmaLinux 10: `kernel-6.12.0-124.56.3.el10_1` oder neuer.
CloudLinux LTS-Kernel	`kernel-lts-5.14.0-284.1101.el8.tuxcare.7.els33` bzw. `kernel-lts-5.14.0-284.1101.el9.tuxcare.7.els33` oder neuer.
Fedora 44	Fixes in `kernel-7.0.6-200.fc44`; aktuelle `7.0.8-200.fc44` enthält zusätzliche skbuff-Fix-Updates.
Amazon Linux / Bottlerocket	Für Fragnesia laut AWS nicht betroffen, weil `espintcp` nicht bereitgestellt wird. Dirty Frag und Copy Fail bleiben davon getrennt zu prüfen.
SUSE Linux Micro 6.0/6.1	SUSE-CVE-Seite: Released.
SUSE Linux Micro 6.2	SUSE-CVE-Seite: Affected.
SLES 15 SP7 / SLES 16.0	Viele Kernelpakete standen auf “In progress”; einzelne Paketlisten nennen Mindeststände, etwa `kernel-default-extra >= 6.4.0-150700.53.52.1` oder `kernel-default >= 6.12.0-160000.31.1` je nach Produkt.
SLES 15 SP4/SP6 LTSS und SAP-Varianten	Gemischter Status aus “In progress” und “Affected”. Beispielstände auf der SUSE-Seite sind produkt- und Service-Pack-spezifisch, etwa `5.14.21-150400.24.214.1` oder `6.4.0-150600.23.109.1`.
SLES 11 SP4	SUSE führt SLES 11 SP4 in den sichtbaren Tabellen als not affected.
Rocky Linux 8/9/10	Keine belastbare Rocky-Mindestversion zum geprüften Stand. Der Dirty-Frag-Security-Repo-Kernel ist kein Fragnesia-Nachweis; im Rocky-Forum wurde der zusätzliche Fixbedarf bestätigt. Mitigation beibehalten, bis ein Fragnesia-Fix eindeutig installiert und aktiv ist.
Oracle Linux 8/9/10	Kein pauschaler Stand ohne Oracle-Erratum. RHCK und UEK getrennt prüfen; KernelCare hatte am 15.05. Livepatch-IDs für Oracle Linux 8/9 und UEK 7 genannt.
Proxmox VE	PSA-2026-00020-1: Trixie-basierte Produkte sind ab `proxmox-kernel-7.0.2-3-pve`, `6.17.13-8-pve` oder `6.14.11-9-pve` gefixt. Bookworm-basierte Produkte sind ab `6.8.12-24-pve` oder `6.14.11-9-bpo12-pve` gefixt. Der frühere Fixstand `7.0.2-2-pve` war laut Forumstest noch ausnutzbar.

Für PVE-Enterprise-Nodes ist der Punkt praktisch: Die Trixie-Enterprise-Changelogs für proxmox-kernel-7.0_7.0.2-3, proxmox-kernel-6.17_6.17.13-8 und proxmox-kernel-6.14_6.14.11-9 enthalten den skbuff-Backport zur shared-frag-Markierung. Bei Bookworm-Nodes zählt der PSA-Fixstand plus das, was dein konfiguriertes Repository per apt-cache policy wirklich anbietet.

Bei Enterprise-Distributionen ist die genaue Paketversion wichtiger als die Upstream-Kernelnummer. Ein 6.1.x- oder 6.12.x-Kernel kann gefixt sein, wenn der Vendor den Patch zurückportiert hat. Umgekehrt kann ein scheinbar neuer Kernel offen sein, wenn genau diese skbuff-Fixes fehlen.

Was ist nicht betroffen oder deutlich entschärft?

Nicht betroffen oder praktisch entschärft sind Systeme, bei denen der verwundbare Pfad nicht vorhanden, nicht erreichbar oder bereits gefixt ist. Das muss man belegen, nicht raten.

Der laufende Kernel enthält die Fragnesia-Fixes für CVE-2026-46300, bei Proxmox also mindestens die in PSA-2026-00020-1 genannten Kernelstände.
Ein Livepatch ist aktiv und nennt CVE-2026-46300 oder die passenden skbuff-Fragnesia-Fixes für exakt den laufenden Kernel.
esp4, esp6 und der konkrete ESP-in-TCP-Pfad über espintcp sind weder geladen noch ladbar, und die Umgebung braucht keine ESP/IPsec-Funktionalität.
Die komplette Dirty-Frag-Mitigation mit esp4, esp6 und rxrpc ist aktiv und im initramfs berücksichtigt.
Der Vendor stuft die konkrete Kernel-Konfiguration als nicht betroffen ein, wie AWS es für Amazon Linux und Bottlerocket getan hat.
KVM-Gäste teilen den Host-Kernel nicht. Sie müssen trotzdem als eigene Linux-Systeme bewertet und gepatcht werden.

Wichtig: “Das Modul ist gerade nicht geladen” reicht nicht. Wenn es durch einen passenden Kernelpfad automatisch geladen werden kann, ist der Host nicht sauber mitigiert. Deshalb arbeiten die Vendor-Mitigationen mit install <modul> /bin/false und nicht nur mit einer einfachen blacklist-Zeile.

Schnelle Prüfung auf einem Host

Zuerst brauchst du den laufenden Kernel:

uname -r
uname -a

Dann prüfst du die installierten Kernelpakete. Auf Debian, Ubuntu und Proxmox:

dpkg -l 'linux-image*' 'linux-modules*' 'proxmox-kernel*' 'pve-kernel*' 2>/dev/null | awk '/^ii/ {print $2, $3}'

Auf RHEL-, Alma-, Rocky-, CloudLinux-, Oracle- und Fedora-nahen Systemen:

rpm -q kernel kernel-core kernel-modules kernel-modules-extra kernel-modules-partner kernel-uek 2>/dev/null
uname -r

Auf SUSE und openSUSE:

zypper se -si 'kernel*'
uname -r

Danach geht es um die betroffenen Module:

grep -E '^(esp4|esp6|rxrpc) ' /proc/modules || echo "esp4/esp6/rxrpc aktuell nicht geladen"
grep -E '^espintcp ' /proc/modules || echo "espintcp aktuell nicht geladen"

Prüfen, ob die Module grundsätzlich im laufenden Kernel vorhanden sind:

find "/lib/modules/$(uname -r)" -type f \( -name 'esp4.ko*' -o -name 'esp6.ko*' -o -name 'rxrpc.ko*' -o -name 'espintcp.ko*' \) -print

Prüfen, ob eine Blockade wirklich greift:

modprobe -n -v esp4
modprobe -n -v esp6
modprobe -n -v espintcp
modprobe -n -v rxrpc

Wenn dort install esp4 /bin/false, install esp6 /bin/false, install espintcp /bin/false und install rxrpc /bin/false erscheint, ist die typische Dirty-Frag-/Fragnesia-Mitigation aktiv. Wenn insmod .../esp4.ko oder ähnliches erscheint, ist das Modul weiterhin ladbar. espintcp ist bei einigen Kerneln direkt einkompiliert statt als Modul vorhanden; dann ist die Kernel-Konfiguration wichtiger als modprobe.

Falls die Kernel-Konfiguration verfügbar ist, prüfe die relevanten Optionen:

grep -E 'CONFIG_XFRM|CONFIG_INET_ESP|CONFIG_INET6_ESP|CONFIG_INET_ESPINTCP|CONFIG_INET6_ESPINTCP' "/boot/config-$(uname -r)" 2>/dev/null || true
zgrep -E 'CONFIG_XFRM|CONFIG_INET_ESP|CONFIG_INET6_ESP|CONFIG_INET_ESPINTCP|CONFIG_INET6_ESPINTCP' /proc/config.gz 2>/dev/null || true

Wenn CONFIG_INET_ESPINTCP nicht gesetzt ist und auch kein espintcp-Modul existiert, fehlt der bekannte Fragnesia-PoC-Pfad. Das ersetzt trotzdem nicht die Vendor-Einschätzung für einen produktiven Kernel, weil Backports und Konfigurationsdetails unterschiedlich sein können.

Für den bekannten PoC-Pfad ist außerdem relevant, ob unprivileged user namespaces möglich sind:

sysctl user.max_user_namespaces 2>/dev/null
sysctl kernel.unprivileged_userns_clone 2>/dev/null
sysctl kernel.apparmor_restrict_unprivileged_userns 2>/dev/null

Das ist kein vollständiger Vulnerability-Scanner. Es beantwortet aber die ersten Betriebsfragen:

Welcher Kernel läuft wirklich?
Sind die betroffenen Module geladen oder ladbar?
Greift eine temporäre Mitigation?
Gibt es lokale Workloads, die aus einem begrenzten Benutzerkontext heraus angreifen könnten?

Updates einspielen

Die saubere Lösung ist ein Kernel-Update aus den Repositories deiner Distribution. Danach muss der Host rebooten oder du musst einen passenden Livepatch nachweisen.

Debian, Ubuntu und Proxmox:

sudo apt update
sudo apt full-upgrade
sudo reboot
uname -r

Auf Proxmox zusätzlich:

pveversion -v
dpkg -l 'proxmox-kernel*' 'pve-kernel*' | awk '/^ii/ {print $2, $3}'
apt-cache policy proxmox-kernel-6.8 proxmox-kernel-6.14 proxmox-kernel-6.17 proxmox-kernel-7.0 2>/dev/null
proxmox-boot-tool status 2>/dev/null || true
apt changelog proxmox-kernel-6.8 proxmox-kernel-6.14 proxmox-kernel-6.17 proxmox-kernel-7.0 2>/dev/null | grep -Ei 'CVE-2026-46300|Fragnesia|shared-frag|skbuff|espintcp' || true

RHEL, AlmaLinux, Rocky Linux, CloudLinux, Oracle Linux und Fedora:

sudo dnf clean metadata
sudo dnf update 'kernel*'
sudo reboot
uname -r

Bei älteren EL-Systemen kann noch yum statt dnf relevant sein.

SUSE und openSUSE:

sudo zypper refresh
sudo zypper patch
sudo reboot
uname -r

Bei Kernel-Livepatching zählt nicht uname -r allein. Der Kernel-Release-String bleibt normalerweise gleich. Du brauchst den Nachweis aus dem Livepatch-Tool:

canonical-livepatch status --verbose 2>/dev/null || true
kpatch list 2>/dev/null || true
kcarectl --patch-info 2>/dev/null | grep -E 'CVE-2026-46300|Fragnesia|shared-frag|skbuff' || true
uptrack-show --available 2>/dev/null || true

Wenn ein Livepatch nur Copy Fail oder Dirty Frag nennt, ist Fragnesia nicht automatisch erledigt. Der Bug braucht einen eigenen Fix.

Auf RHEL-, Alma-, Rocky-, CloudLinux- und Fedora-nahen Systemen ist nach Kernelupdates außerdem needs-restarting hilfreich:

needs-restarting -r 2>/dev/null || true

Auf Debian und Ubuntu erfüllen needrestart oder checkrestart denselben Zweck als Zusatzsignal:

needrestart -r l 2>/dev/null || true
checkrestart 2>/dev/null || true

Das ersetzt nicht uname -r. Es hilft aber, Hosts zu finden, bei denen ein Kernelupdate installiert wurde und der Reboot noch fehlt.

Temporäre Mitigation

Wenn ein Kernel-Fix noch nicht verfügbar ist oder ein sofortiger Reboot nicht geht, bleibt die Modul-Blockade. Vorher musst du prüfen, ob der Host IPsec oder AFS/RxRPC wirklich nutzt.

IPsec-Indizien:

lsmod | grep -E '^(esp4|esp6)'
ip xfrm state show 2>/dev/null
ip xfrm policy show 2>/dev/null
systemctl status strongswan 2>/dev/null || true
systemctl status ipsec 2>/dev/null || true
systemctl status libreswan 2>/dev/null || true

RxRPC/AFS-Indizien:

lsmod | grep -E '^rxrpc'
mount | grep -i afs || true

Wenn die Module nicht gebraucht werden, ist die typische Blockade:

printf '%s\n' \
  'install esp4 /bin/false' \
  'install esp6 /bin/false' \
  'install espintcp /bin/false' \
  'install rxrpc /bin/false' \
  | sudo tee /etc/modprobe.d/dirtyfrag-fragnesia.conf

for module in esp4 esp6 espintcp rxrpc; do
  if grep -q "^${module} " /proc/modules; then
    sudo rmmod "$module" || echo "WARNUNG: $module konnte nicht entladen werden"
  fi
done

grep -qE '^(esp4|esp6|espintcp|rxrpc) ' /proc/modules \
  && echo "Mindestens ein Dirty-Frag-/Fragnesia-Modul ist noch geladen" \
  || echo "esp4/esp6/espintcp/rxrpc sind aktuell nicht geladen"

Wenn du diese Mitigation über einen Reboot hinweg brauchst, muss sie auch im initramfs landen. Sonst kann ein früh geladenes Modul beim nächsten Boot wieder aktiv sein.

Auf Debian und Ubuntu:

sudo update-initramfs -u -k all

Auf RHEL-, Alma-, Rocky-, CloudLinux-, Oracle- und Fedora-nahen Systemen:

sudo dracut -f

Bei SUSE ist je nach Setup ebenfalls ein initramfs-Update nötig, wenn die Module früh geladen werden:

sudo dracut -f

Die Blockade zurücknehmen, nachdem ein gefixter Kernel installiert und aktiv ist:

sudo rm /etc/modprobe.d/dirtyfrag-fragnesia.conf

if command -v update-initramfs >/dev/null; then
  sudo update-initramfs -u -k all
fi

if command -v dracut >/dev/null; then
  sudo dracut -f
fi

Danach rebooten oder nach Vendor-Anweisung sicherstellen, dass die alte Blockade nicht mehr aus einem initramfs oder Konfigurationsmanagement zurückkommt.

Was beim Patchen gern schiefgeht

Der erste Fehler ist ein installiertes Kernelpaket ohne Reboot. Dann liegt der Fix auf der Platte, aber der alte Kernel läuft weiter.

Prüfe nach dem Wartungsfenster immer:

uname -r

und vergleiche den laufenden Kernel mit dem installierten Paketstand und dem Vendor-Tracker.

Der zweite Fehler ist, Dirty Frag und Fragnesia zu vermischen. Die Mitigation überschneidet sich. Der Kernel-Fix aber nicht zwingend. Ein Dirty-Frag-Hotfix aus der letzten Woche kann gegen Fragnesia offen bleiben.

Der dritte Fehler ist eine blinde Modul-Blockade auf IPsec-Systemen. esp4 und esp6 sind nicht dekorativ. Wer strongSwan, Libreswan, site-to-site-VPNs oder IPsec-basierte Kundentunnel betreibt, kann sich mit der Mitigation produktive Verbindungen abschießen.

Der vierte Fehler ist “Container aktualisiert, Host vergessen”. Docker-, Kubernetes- und LXC-Container bringen keinen eigenen Kernel mit. Der Host entscheidet.

Der fünfte Fehler ist zu frühes Aufräumen alter Kernel. Gerade bei Proxmox, ZFS-Boot und Secure Boot sollte ein bekannter Fallback-Kernel erhalten bleiben, bis der neue Kernel sauber gebootet hat und Netzwerk, Storage, Cluster und Backups geprüft sind.

Der sechste Fehler ist fehlende Reihenfolge im Cluster. Kubernetes-Nodes werden gedraint, Proxmox-HA-Workloads migriert oder bewusst gestoppt, CI-Runner aus der Queue genommen. Der Reboot ist Teil des Fixes.

Für Kubernetes gehört danach ein kurzer Node-Check dazu:

kubectl get nodes -o custom-columns='NAME:.metadata.name,KERNEL:.status.nodeInfo.kernelVersion,OS:.status.nodeInfo.osImage'
kubectl describe node <node-name> | grep -E 'Kernel Version|OS Image|Container Runtime'

Wenn ein Node nach dem Drain/Reboot noch mit dem alten Kernel zurückkommt, war das Wartungsfenster nicht fertig.

Kleine Flottenprüfung

Für viele Hosts brauchst du zuerst keine perfekte Inventarlösung, sondern einen schnellen Überblick. Eine einfache SSH-Schleife reicht für die erste Triage:

for host in server1 server2 server3; do
  echo "===== $host"
  ssh "$host" 'uname -r; modprobe -n -v esp4 2>&1 | head -1; modprobe -n -v esp6 2>&1 | head -1; modprobe -n -v espintcp 2>&1 | head -1'
done

Mit Ansible geht derselbe erste Blick ohne eigenes Playbook:

ansible all -m shell -a 'uname -r; modprobe -n -v esp4 2>&1 | head -1; modprobe -n -v esp6 2>&1 | head -1; modprobe -n -v espintcp 2>&1 | head -1' -o

Das ist keine finale Compliance-Prüfung. Es zeigt aber schnell, welche Hosts noch genauer gegen Vendor-Fixes, Modulstatus und Reboot-Stand geprüft werden müssen.

Page Cache nach Test oder Verdacht

Fragnesia manipuliert Page-Cache-Seiten. Wenn ein Host bereits angegriffen wurde oder jemand den PoC auf einem Lab-System gestartet hat, reicht “Prozess beendet” nicht. Die manipulierte Page-Cache-Kopie kann weiter verwendet werden, bis sie verdrängt oder der Host rebootet wird.

Auf einem isolierten Lab-System reicht danach normalerweise:

sync
echo 3 | sudo tee /proc/sys/vm/drop_caches >/dev/null

Auf einem produktiven System mit Verdacht auf echte Ausnutzung ist das keine vollständige Incident Response. Wenn jemand über Fragnesia Root bekommen hat, kann er danach Persistenz eingerichtet, Logs verändert oder Secrets gelesen haben. Dann gehören mindestens Isolierung, Log- und EDR-Prüfung, Secret-Rotation und je nach System ein sauberer Rebuild auf die Liste.

Datei-Hashes allein beweisen hier wenig. Der Trick ist ja gerade, dass die Datei auf der Platte unverändert bleiben kann.

Einordnung für Plesk, Proxmox und Hosting

Für Plesk-Server ist Fragnesia besonders relevant, weil Plesk-Hosts oft viele lokale Benutzer und voneinander getrennte Website-Kontexte haben: PHP-FPM-Pools, Cronjobs, SSH-Zugänge, Backups, Deployment-Scripte und Kundenprozesse. Plesk patcht hier nicht den Kernel. Entscheidend ist das Betriebssystem darunter.

Bei Proxmox ist die Trennung wichtig:

Proxmox-Host: Der Host-Kernel muss gefixt oder mitigiert sein. Hooks, Backup-Scripte, Admin-Shells und Automatisierung laufen nahe am Host.
LXC-Container: LXC teilt den Host-Kernel. Ein verwundbarer Host-Kernel ist deshalb direkt relevant.
KVM-VMs: KVM-Gäste haben eigene Kernel. Ein Exploit im Gast ist nicht automatisch ein Exploit im Host. Die Gäste müssen trotzdem separat gepatcht werden.
Cluster: Reboots brauchen Reihenfolge. Dokumentiere, welcher Node mit welchem Kernel läuft und wo eine temporäre Mitigation aktiv ist.

Der neue Proxmox-Stand ändert die praktische Bewertung: PVE 9 mit Kernel 7.0.2-2-pve war laut Forumstest noch nicht sicher, obwohl dieser Stand bereits Dirty-Frag-Fixes enthält. Für Fragnesia zählt PSA-2026-00020-1: 7.0.2-3-pve, 6.17.13-8-pve, 6.14.11-9-pve, 6.8.12-24-pve oder 6.14.11-9-bpo12-pve und danach ein Reboot in genau diesen Kernel. Bis dahin bleibt die Modul-Mitigation der belastbare Zwischenzustand.

Für Hoster, Agenturen und MSPs ist die Priorisierung klar: Systeme mit fremdem oder schwer kontrollierbarem Code zuerst. Dazu gehören Shared Hosting, Build-Server, GitLab Runner, Kubernetes-Nodes, Docker-Hosts mit Kundenworkloads und Proxmox-Hosts mit LXC-Containern.

Wie wir damit umgehen würden

Bei einem produktiven Setup würde ich nicht mit “einmal update && reboot” anfangen, sondern mit einer sauberen Hostliste:

Hosts aus Inventar, Monitoring, Proxmox, Cloud, Plesk und CI ziehen.
Systeme nach Risiko sortieren: Shared Hosting, Container, CI, Shell-Zugänge und Multi-Tenant zuerst.
Pro Host laufenden Kernel, installierte Kernelpakete und betroffene Module prüfen.
Vendor-Fixes gegen Debian/Ubuntu/Red Hat/SUSE/Alma/CloudLinux/Fedora/Proxmox-Paketstand abgleichen.
Wenn kein Fix oder kein sofortiger Reboot möglich ist: Modul-Mitigation mit IPsec-/AFS-Prüfung.
Reboot- oder Livepatch-Nachweis dokumentieren.
Nachkontrolle: laufender Kernel, Modulstatus, Monitoring und offene Hosts.
Bei Verdacht auf Ausnutzung nicht nur Cache leeren, sondern Incident-Pfad starten.

Wenn du im selben Wartungsfenster auch ssh-keysign-pwn (CVE-2026-46333) abarbeiten willst, ist der Kernel-Fix derselbe, aber der Patch-Nachweis und eine mögliche Secret-Rotation für SSH-Host-Keys und Shadow-Hashes kommen als eigener Schritt dazu.

Wenn du nicht sicher bist, ob deine Server wirklich gefixt sind, ist ein kurzer Security- und Kernel-Check sinnvoller als blindes Patchen unter Zeitdruck. Gerade bei Plesk-, Proxmox-, Container- und VPN-Umgebungen ist die Frage nicht nur “Update ja/nein”, sondern “welcher Host kann wann rebooten, welche Dienste brechen durch die Mitigation, und wie belegen wir danach den Zustand?”

Update-Log

2026-05-13: Fragnesia wurde öffentlich gemacht. V12 veröffentlichte PoC und Write-up. Canonical, AlmaLinux, CloudLinux, Red Hat, AWS und weitere Vendoren begannen mit Advisories oder Mitigationen.
2026-05-13: Der initiale Upstream-Fix wurde auf der Netdev-Liste diskutiert. Kernpunkt: skbuff muss die shared-frag-Markierung beim Coalescing erhalten.
2026-05-14: Erste Vendor-Hinweise machten klar, dass Fragnesia ein eigener Bug ist. Dirty-Frag-Mitigationen helfen, Dirty-Frag-Kernel-Fixes aber nicht zwingend.
2026-05-15: CloudLinux meldete finale CL7h-/CL8-Kernelziele, aktualisierte Alma-/CL9-/CL10-Zielstände und KernelCare-Livepatch-Wellen. Fedora-Kernel enthielten weitere skbuff-Fixes.
2026-05-16: AlmaLinux veröffentlichte gepatchte Kernel für AL8, AL9 und AL10 in den Production-Repositories.
2026-05-17: Artikel angelegt. Patchstände gegen öffentlich verfügbare Vendor-Tracker, Advisories und Paket-Changelogs geprüft.
2026-05-17: Ergänzt: espintcp-Prüfung, Kernel-Konfigurationsflags, Upstream-Fix-Kontext, Rocky-/Proxmox-Status klarer formuliert, XFRM-Laufzeitchecks, Reboot-Hinweise für needs-restarting/needrestart, Kubernetes-Node-Check und kleine Flottenprüfung.
2026-05-18: Proxmox-Stand aktualisiert: PSA-2026-00020-1 nennt eigene Fragnesia-Fixstände für proxmox-kernel-7.0, 6.17, 6.14, 6.8 und 6.14-bpo12. Der alte Forumshinweis zu 7.0.2-2-pve bleibt als Negativbeispiel im Text. Rocky-Stand bestätigt: Red Hat hat noch keinen Fix veröffentlicht, Rocky nennt noch keinen ETA.