Fragnesia (CVE-2026-46300): Linux-Root-Lücke erkennen und absichern

Stand: 14. Mai 2026 - zuletzt aktualisiert

Autor: Mika Schmidt (IT-Security Experte) – Six Eight Consulting, Fokus: Analyse, IAM, Security Engineering.

Fragnesia (CVE-2026-46300) ist die nächste Linux-Kernel-Schwachstelle, die Security-Teams ernst nehmen sollten: lokale Privilegieneskalation, öffentlicher Proof of Concept und ein Angriffsmodell, das besonders in Cloud-, Container- und CI/CD-Umgebungen unangenehm wird. Ubuntu stuft die CVE als High Priority ein, AlmaLinux spricht von betroffenen Enterprise-Kernel-Reihen, Debian markiert mehrere Linux-Pakete als verwundbar. [Vendor Advisory] [Vendor Advisory] [Vendor Tracker]

Wichtig für die Einordnung: Fragnesia ist nach aktueller öffentlicher Analyse keine alleinstehende Remote-Code-Execution aus dem Internet. Der Angreifer braucht lokalen Code-Ausführungskontext. Genau das ist in der Praxis aber oft gegeben: ein kompromittierter Webservice, ein bösartiger CI-Job, ein Container-Foothold, SSH-Zugang mit niedrigem Benutzerrecht oder ein Entwicklerkonto mit eingeschränkten Rechten. [Disclosure] [Analyse]

Was ist Fragnesia (CVE-2026-46300)?

Technisch ist Fragnesia eng mit der Angriffsoberfläche verwandt, die kurz zuvor bei Dirty Frag diskutiert wurde. In der veröffentlichten Analyse geht es darum, dass der Kernel beim Umgang mit Socket Buffern und page-cache-backed Fragments nicht durchgehend erkennt, dass bestimmte Fragmente geteilt beziehungsweise extern hinterlegt sind. Der netdev-Patch adressiert genau dieses Problem: Der Marker für geteilte Fragmente soll beim Coalescing erhalten bleiben. [Patch]

Für die Praxis reicht diese Kurzfassung: Ein Angreifer, der bereits lokalen Code ausführen kann, bekommt unter bestimmten Bedingungen einen Weg von "niedrige Rechte" zu Root. Das ist dieselbe operative Risikoklasse, die Copy Fail und Dirty Frag so gefährlich macht: Nicht der erste Zugriff ist das Hauptproblem, sondern die schnelle Eskalation danach. [Hintergrund]

Warum ist das für Unternehmen kritisch?

Lokale Kernel-LPEs werden gerne unterschätzt, weil sie nicht wie ein klassischer "Port offen, Server übernommen"-Exploit aussehen. In modernen Infrastrukturen ist lokaler Code-Ausführungskontext aber kein exotisches Szenario. CI/CD-Runner führen Pull-Request-Code aus. Kubernetes-Nodes hosten Workloads unterschiedlicher Teams. Webserver, Worker und Applikationsprozesse laufen bewusst mit eingeschränkten Rechten. Genau diese Begrenzung kann eine Kernel-LPE aushebeln.

Bin ich betroffen?

Die sauberste Antwort kommt von Ihrem Distributor: Ubuntu, Debian, AlmaLinux, Red Hat, SUSE, Fedora, Rocky, CloudLinux und andere pflegen eigene Kernel-Pakete, Backports und Security-Tracker. Verlassen Sie sich deshalb nicht allein auf die Upstream-Kernelnummer. Ein alter Kernel kann gepatcht sein, ein neuerer Kernel kann in einer bestimmten Distribution noch in Bewertung sein.

Als Faustregel gilt: Sie sollten aktiv prüfen, wenn Sie Linux-Systeme betreiben, auf denen einer der folgenden Punkte zutrifft:

• Untrusted lokale Nutzer können sich anmelden oder Jobs ausführen.
• CI/CD-Runner, Build-Server oder Testsysteme führen Fremdcode aus.
• Container- oder Kubernetes-Workloads laufen auf gemeinsam genutzten Hosts.
• User Namespaces sind für unprivilegierte Nutzer erlaubt.
• esp4, esp6 oder rxrpc sind geladen oder können geladen werden.
• Der Distributor markiert Ihre Kernel-Reihe als "vulnerable", "needed", "needs evaluation" oder noch nicht gefixt.

Ubuntu nennt als Mitigation explizit dieselbe Vorgehensweise wie bei Dirty Frag. Debian listet zum Zeitpunkt dieses Artikels mehrere Kernel-Reihen als verwundbar. AlmaLinux berichtet, dass gepatchte Kernel in Testing verfügbar sind. [Vendor Advisory] [Vendor Tracker] [Vendor Advisory]

Schnellcheck: Kernel, Module, Namespaces

Der folgende Check beweist keine Verwundbarkeit und führt keinen Exploit aus. Er sammelt die Informationen, die Sie für die Priorisierung brauchen: Kernel, Distribution, geladene Module und Namespace-Konfiguration.

# Basisdaten für Fragnesia / CVE-2026-46300 sammeln
uname -a
cat /etc/os-release 2>/dev/null

# Sind die relevanten Module aktuell geladen?
lsmod | grep -E '^(esp4|esp6|rxrpc)\b' || echo "esp4/esp6/rxrpc aktuell nicht geladen"

# Dürfen unprivilegierte Nutzer User Namespaces erstellen?
sysctl kernel.unprivileged_userns_clone 2>/dev/null || true

# Distributor-Fixstatus prüfen:
# Debian/Ubuntu: apt list --upgradable | grep -E 'linux-image|linux-generic|linux-headers'
# RHEL/Alma/Rocky/Fedora: dnf updateinfo list cves | grep CVE-2026-46300
# SUSE: zypper list-patches --cve=CVE-2026-46300

Wenn die Module nicht geladen sind, ist das ein gutes Zeichen, aber kein vollständiger Fix: Module können später geladen werden, wenn sie nicht blockiert sind. Wenn Sie IPsec/ESP oder AFS/RxRPC produktiv nutzen, prüfen Sie vor einer Mitigation die Auswirkungen auf VPN, Storage, Legacy-Services und Netzwerkfunktionen.

Wie kann ich CVE-2026-46300 fixen?

Der eigentliche Fix ist ein gepatchter Kernel Ihres Distributors plus Neustart in genau diesen Kernel. Bei Kernel-Schwachstellen reicht es nicht, Pakete nur herunterzuladen. Der laufende Kernel bleibt aktiv, bis das System neu startet oder ein sauber unterstütztes Live-Patching greift.

1. Vendor-Status prüfen: Ubuntu, Debian, Red Hat, AlmaLinux, Rocky, SUSE, Fedora, CloudLinux oder Ihren Cloud-Anbieter.
2. Kernel-Update installieren: bevorzugt über den normalen Paketmanager oder das zentrale Patch-Management.
3. Neustart planen: nach dem Reboot mit uname -r prüfen, dass der neue Kernel wirklich läuft.
4. Mitigation entfernen oder beibehalten: Wenn Sie Module blockiert haben, erst nach bestätigtem Fix und Betriebsfreigabe zurücknehmen.

# Debian / Ubuntu
sudo apt update
sudo apt full-upgrade
sudo reboot

# RHEL / AlmaLinux / Rocky Linux / Fedora
sudo dnf update kernel\*
sudo reboot

# SUSE / openSUSE
sudo zypper patch --category security
sudo reboot

# Nach dem Neustart:
uname -r

Für Enterprise-Umgebungen gilt: Patchen Sie zuerst Systeme mit untrusted Code-Ausführung. Ein interner Datenbankserver ohne lokale Nutzer ist wichtig, aber ein Internet-naher Container-Host oder CI-Runner ist in der Regel dringender.

Mitigation, bis der Kernel-Fix aktiv ist

Wenn ein Vendor-Kernel noch nicht verfügbar ist oder Sie den Neustart nicht sofort durchführen können, empfiehlt Ubuntu für CVE-2026-46300 die gleiche Vorgehensweise wie bei Dirty Frag: esp4, esp6 und rxrpc blockieren und bereits geladene Module entladen. [Vendor Advisory] [Mitigation]

# Mitigation: Module blockieren
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' | sudo tee /etc/modprobe.d/fragnesia.conf

# Debian/Ubuntu: initramfs aktualisieren
sudo update-initramfs -u -k all

# RHEL/Alma/Rocky/Fedora/SUSE: falls genutzt, initramfs neu generieren
sudo dracut -f --regenerate-all 2>/dev/null || true

# Bereits geladene Module entladen, sofern nicht in Benutzung
sudo rmmod esp4 esp6 rxrpc 2>/dev/null || true

# Page Cache leeren; kann kurzzeitig Performance beeinflussen
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

# Kontrolle
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Module sind noch geladen" || echo "Module sind nicht geladen"

Diese Mitigation ist nicht für jede Umgebung kostenlos. Wer IPsec ESP, bestimmte VPN-Szenarien oder RxRPC/AFS nutzt, kann damit Funktionalität brechen. In solchen Fällen sollten Sie die Hosts isolieren, den Patch beschleunigen und die Entscheidung dokumentieren, statt blind Module zu deaktivieren.

Priorisierung: Was heute passieren sollte

Wenn Sie Hinweise auf Missbrauch haben, behandeln Sie den Host nicht nur als "patchbedürftig", sondern als möglicherweise kompromittiert: isolieren, volatile Artefakte sichern, lokale Root-Aktivitäten und SUID-Binaries prüfen, Secrets rotieren und den Host aus sauberer Quelle neu aufbauen, wenn die Integrität nicht belastbar nachweisbar ist.

Copy Fail, Dirty Frag und Fragnesia: warum die Serie zählt

Fragnesia ist nicht einfach "noch eine CVE". Die Schwachstelle erscheint in einer auffälligen Serie von Linux-Kernel-LPEs rund um Page Cache, Kryptografie-/Netzwerkpfade und Kernel-Subsysteme, die in Cloud- und Container-Umgebungen besonders relevant sind. Microsoft hatte Copy Fail bereits als ernstes Risiko für Cloud-Linux-Workloads und Kubernetes-Cluster eingeordnet. Fragnesia liegt nicht identisch, aber operativ in einer sehr ähnlichen Risikoklasse. [Hintergrund]

Die Lehre für Unternehmen ist schlicht: Kernel-Patching gehört in dieselbe Prioritätsklasse wie Exposure-Management und CI/CD-Hardening. Wer untrusted Code ausführt, braucht schnelle Kernel-Rollouts, kurzlebige Runner, harte Mandantentrennung und klare Entscheidungswege für außerplanmäßige Reboots.

FAQ zu Fragnesia (CVE-2026-46300)

Was ist Fragnesia (CVE-2026-46300)?

Fragnesia ist eine lokale Privilegieneskalation im Linux-Kernel. Die Schwachstelle liegt im Umfeld von XFRM/IPsec ESP-in-TCP und RxRPC und kann dazu führen, dass ein lokaler, unprivilegierter Prozess Daten im Page Cache read-only Dateien manipuliert und Root-Rechte erreicht.

Ist CVE-2026-46300 aus dem Internet remote ausnutzbar?

Nach der aktuellen öffentlichen Einordnung ist Fragnesia keine klassische Remote-Code-Execution. Ein Angreifer braucht zunächst lokalen Code-Ausführungskontext, etwa Shell-Zugang, kompromittierte CI-Jobs, Container-Workloads oder einen anderen Initialzugriff.

Welche Linux-Systeme sind besonders relevant?

Priorität haben Systeme mit untrusted lokalen Nutzern oder Workloads: Container-Hosts, Kubernetes-Nodes, CI/CD-Runner, Build-Server, Shared-Hosting-Systeme, Jump-Hosts, Developer-Workstations und Server, auf denen Angreifer nach Initialzugriff Code ausführen könnten.

Wie prüfe ich, ob ich betroffen bin?

Prüfen Sie Kernel-Version, Distribution Security Tracker, ob esp4, esp6 oder rxrpc geladen sind, und ob unprivilegierte Nutzer Namespaces erstellen dürfen. Maßgeblich bleibt der Patch-Status Ihres Distributors, nicht nur die reine Upstream-Kernelnummer.

Wie behebe ich Fragnesia?

Installieren Sie den vom Distributor bereitgestellten Kernel-Fix und starten Sie das System neu. Bis der Fix verfügbar und aktiv ist, können Sie esp4, esp6 und rxrpc per modprobe-Konfiguration blockieren und bereits geladene Module entladen, sofern Ihr Betrieb diese Funktionen nicht benötigt.

Reicht Container-Isolation als Schutz?

Nein, nicht als alleinige Maßnahme. Lokale Kernel-LPEs sind gerade auf Container-Hosts kritisch, weil Container denselben Kernel teilen. Behandeln Sie untrusted Container- oder CI-Ausführung als prioritären Patch- und Mitigation-Kontext.