Gepatchte Kernel gegen Fragnesia (CVE-2026-46300) gibt es seit Mai, etwa bei AlmaLinux, Debian und Ubuntu. CISA hat die lokale Rechteausweitung am 28.10.2026 in den KEV-Katalog aufgenommen, also in die Liste nachweislich ausgenutzter Schwachstellen. Laut CISA lässt sich Fragnesia mit zwei PHP-Lücken verketten, um Befehle als root auszuführen, und der Eintrag verlangt eine forensische Prüfung statt nur eines Updates.
Betroffen sind Linux-Server, auf denen die Kernel-Module esp4, esp6 oder rxrpc geladen werden können. Wer nicht sofort neu starten kann, blockiert laut AlmaLinux diese Module, muss dann aber auf IPsec ESP und AFS verzichten. Die Reihenfolge, die sich daraus ergibt: erst prüfen, dann patchen, dann neu starten und die Kernelversion kontrollieren.
Was im KEV-Eintrag steht
Der KEV-Katalog (Known Exploited Vulnerabilities) der US-Behörde CISA listet Schwachstellen, für die eine Ausnutzung in der Praxis vorliegt. Fragnesia kam laut CISA-Meldung vom 28.10.2026 gemeinsam mit einer zweiten Lücke hinzu. Als Frist (dueDate) nennt der Eintrag den 31.10.2026. Diese Frist ist nur für US-Bundesbehörden verbindlich; für alle anderen ist sie ein Richtwert dafür, wie dringlich CISA die Sache einstuft.
Auffällig ist das Feld zur forensischen Prüfung (forensicTriage), das bei diesem Eintrag auf „Yes“ steht. CISA erwartet also, dass Betreiber nicht nur patchen, sondern untersuchen, ob ein System bereits kompromittiert wurde. Das ist bei Kernel-Lücken nicht selbstverständlich, denn ein Patch schließt die Lücke, entfernt aber keine Spuren eines früheren Zugriffs.
Fragnesia selbst ist eine lokale Rechteausweitung: Wer bereits Code auf dem System ausführen kann, kann seine Rechte erhöhen. Aus der Ferne wird daraus erst eine Gefahr durch die Verkettung. Laut CISA lässt sich Fragnesia mit CVE-2026-109618 und CVE-2026-109619 kombinieren, um PHP-Webshells abzulegen und Befehle als root auszuführen. Die PHP-Lücken sind der Zugang, der Kernel-Fehler hebt die Rechte an.
Der Schwachstellentyp ist als CWE-456 eingeordnet, fehlende Initialisierung. Konkret geht beim Zusammenführen von Netzwerkpuffern im Kernel (skb-Coalescing) eine Markierung für geteilte Speicherfragmente verloren. Der Kernel behandelt solche Daten dann, als gehörten sie niemandem sonst.
Die PHP-Seite hatte CISA bereits am 21.10.2026 in einer Warnung zu kritischen PHP-Lücken behandelt. Behoben sind sie in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35; am 26.10.2026 wurden sie in den KEV-Katalog aufgenommen. Wer PHP-Anwendungen betreibt, hat damit zwei Baustellen, die zusammengehören.
dm-Rechnung: Die gepatchten AlmaLinux-Kernel sind seit dem 16.05.2026 in Produktion, die KEV-Aufnahme folgte am 28.10.2026. Von Mai bis Oktober hat Mai 15 Tage, Juni 30, Juli 31, August 31, September 30 und Oktober 28 Tage; abzüglich der 16 Mai-Tage vor dem Patch ergeben sich 15 + 30 + 31 + 31 + 30 + 28 = 165 Tage. Systeme, die seither nicht aktualisiert wurden, liefen also fast ein halbes Jahr mit verfügbarem Fix, aber offener Lücke.
Offen bleibt, wer die Lücke ausnutzt; eine Angreifergruppe nennt CISA nicht.
Welche Kernel den Fix enthalten
Die Fixes liegen bei den großen Distributionen seit Mai vor. Maßgeblich ist jeweils die Paketversion des Distributionskernels, nicht die Upstream-Versionsnummer, weil die Hersteller Korrekturen in ältere Kernelzweige zurückportieren.
AlmaLinux 8, 9 und 10
Laut AlmaLinux-Blog vom 13.05.2026 (aktualisiert am 16.05.) enthalten diese Kernel den Fix: AlmaLinux 8 kernel-4.18.0-553.124.3.el8_10, AlmaLinux 9 kernel-5.14.0-611.54.5.el9_7 und AlmaLinux 10 kernel-6.12.0-124.56.3.el10_1. Sie sind seit dem 16.05.2026 in Produktion. Betroffen sind die Module esp4 und esp6 sowie rxrpc, Letzteres nur unter AlmaLinux 9 und 10 mit installiertem Paket kernel-modules-partner. Der Fix deckt zudem die Lücke ssh-keysign-pwn (CVE-2026-46333) ab.
Debian
Der Debian Security Tracker nennt als behobene Versionen: bullseye 5.10.257-1 (DLA-4606-1), bookworm 6.1.174-1 (DSA-6306-1) und trixie 6.12.90-1 (DSA-6295-1). Bullseye läuft damit über den Langzeit-Support (DLA), die beiden anderen Releases über reguläre Sicherheitshinweise (DSA).
Ubuntu
Ubuntu führt die Lücke in der CVE-Übersicht mit hoher Priorität. Behoben ist sie in Ubuntu 26.04 mit 7.0.0-22.22, in 25.10 mit 6.17.0-35.35, in 24.04 mit 6.8.0-124.124 und in 22.04 mit 5.15.0-181.191. Ubuntu 20.04 und älter sowie 26.10 sind nicht betroffen.
Zur Einordnung des eigenen Distributionsstands hilft ein Blick auf die Kennungen. Debian führt DSA für Korrekturen in der aktuellen Stable-Linie, DLA für Korrekturen in der Langzeitunterstützung, hier also bei bullseye. Beides bedeutet: Es gibt einen gepatchten Kernel, der eingespielt werden muss. Ubuntu stuft die Lücke mit der Priorität hoch ein, was bei der Reihenfolge der Updates Gewicht haben sollte. Bei AlmaLinux 9 und 10 lohnt der Blick auf kernel-modules-partner, denn nur dort kommt rxrpc als dritter betroffener Baustein hinzu. Wer das Paket nicht installiert hat, muss sich um dieses Modul auf diesen Systemen nicht sorgen, behandelt aber esp4 und esp6 weiterhin. dm-Einordnung: Für alle anderen Distributionen sind deren eigene Sicherheitshinweise maßgeblich. Wer dort keinen Hinweis findet, sollte beim Hersteller nachfragen, statt aus dem Schweigen auf Sicherheit zu schließen.
Wichtig für die Einordnung: Eine installierte Paketversion ist erst wirksam, wenn der Rechner damit gebootet wurde. Ein Server, auf dem das Paket aktualisiert, aber nie neu gestartet wurde, läuft weiter mit dem alten Kernel.
Übergang ohne Neustart
Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptAisle of a server room with rack-mounted Linux servers, blinking status LEDs, a laptop on a cart in the foreground, cool blue lighting. Photorealistic editorial magazine photo, 16:9. Absolutely no text, no letters, no numbers, no logos, no brand marks.Wenn ein Neustart nicht sofort möglich ist, nennt AlmaLinux eine Übergangsmaßnahme: Die Module esp4, esp6 und rxrpc lassen sich per modprobe-Konfiguration am Laden hindern. Es ist dieselbe Maßnahme, die AlmaLinux schon bei Dirty Frag empfohlen hat, und wie der Patch-Ablauf damals aussah, zeigt das Kernel-Update gegen Dirty Frag.
Die Blockade hat einen Preis. Systeme, die IPsec ESP nutzen, also verschlüsselte VPN-Tunnel auf Kernel-Ebene, verlieren dann ihre Verbindungen. Dasselbe gilt für AFS, das Netzwerkdateisystem, das auf rxrpc aufsetzt. Wer die Konfiguration anlegt, ohne vorher zu klären, ob ein Standort-VPN oder ein AFS-Zugriff darauf läuft, trennt im ungünstigen Fall produktive Verbindungen.
Deshalb ist vor der Blockade zu klären, ob die Module überhaupt in Gebrauch sind. Ein Webserver ohne IPsec und ohne AFS verliert durch die Sperre nichts, ein VPN-Gateway dagegen seine Funktion. Das ist eine dm-Einordnung aus der Beschreibung von AlmaLinux, keine Herstellerempfehlung für einzelne Systemtypen.
Ebenso wichtig: Die Blockade ersetzt den Patch nicht. Sie verhindert nur, dass die betroffenen Module geladen werden. Die Ursache im Kernel bleibt bestehen, bis der gepatchte Kernel läuft. Ein Konfigurationseintrag sollte deshalb nach dem Neustart bewusst wieder entfernt oder dokumentiert werden, damit er später nicht unbemerkt IPsec-Verbindungen stört.
Auch auf virtualisierten Umgebungen gilt der Kernel des jeweiligen Systems. Wer Hypervisor-Hosts betreibt, sollte vorab klären, was ein Host-Neustart für laufende Gäste bedeutet, und kann sich am Kernel-Patch auf KVM-Hosts orientieren. Hier lohnt es, Wartungsfenster für Host und Gäste zusammen zu planen.
dm-Einordnung: Eine Sperre der Module ist nur dann belastbar, wenn sie nachvollziehbar festgehalten wird. Sinnvoll ist ein Change-Vermerk, der die Maßnahme, das Datum und den Grund nennt, dazu die Dienste, die betroffen sein könnten, etwa IPsec-Tunnel oder AFS-Zugriffe. Ebenso gehört der geplante Neustarttermin hinein, damit die Übergangslösung nicht dauerhaft unbemerkt bleibt. Das Team im Betrieb weiß dann, warum ein Dienst ausfällt, falls doch etwas von den Modulen abhing. Wichtig ist außerdem: Auch Systeme, auf denen die Module gar nicht geladen sind, brauchen den Kernel-Patch. Die Sperre mindert das Risiko nur vorübergehend, und ein ungeladenes Modul ist kein Beleg dafür, dass ein System dauerhaft sicher ist.
Die Übergangslösung ist damit ein Werkzeug für die Zeit bis zum Wartungsfenster, nicht für den Dauerbetrieb.
Prüfen, patchen, kontrollieren
Die Reihenfolge ist eine dm-Einordnung, abgeleitet aus der Beschreibung von AlmaLinux: Der Exploit verändert Page-Cache-Seiten sensibler Dateien, also die im Arbeitsspeicher gehaltenen Kopien. Das Leeren des Page-Cache entfernt die manipulierten Seiten. Ein Neustart leert den Cache. Wer vor dem Reboot nichts sichert, vernichtet damit möglicherweise genau die Spuren, die CISA mit der forensischen Prüfung sucht.
Praktisch heißt das: Zuerst klären, ob das System über PHP erreichbar war und ob dort die Lücken CVE-2026-109618 oder CVE-2026-109619 offen waren. Auffällige PHP-Dateien im Webverzeichnis, Protokolle und gegebenenfalls ein Speicherabbild sollten gesichert werden, bevor der Rechner neu startet. Verdächtige Systeme gehören in die Hand eines Incident-Response-Teams, nicht in einen hastigen Reboot.
Danach folgt der Patch. Unter AlmaLinux genügt dnf clean metadata && dnf upgrade, anschließend ein Neustart. Bei Debian und Ubuntu läuft das Update über die üblichen Paketwerkzeuge, Zielstand sind die jeweils genannten fehlerbereinigten Kernelversionen. Parallel sind die PHP-Installationen auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 zu bringen, je nach eingesetztem Zweig, weil sonst die Verkettung weiter möglich bleibt.
Zum Schluss steht die Kontrolle. Mit uname -r zeigt sich, welcher Kernel tatsächlich läuft, mit rpm -q kernel unter AlmaLinux, welche Kernelpakete installiert sind. Beide Werte müssen zusammenpassen: Läuft noch die alte Version, obwohl das neue Paket installiert ist, fehlt der Neustart. Auf Debian- und Ubuntu-Systemen ist die laufende Version mit den Tabellenwerten der jeweiligen Distribution abzugleichen.
dm-Einordnung: Auch Systeme, die seit Mai gepatcht und neu gestartet wurden, können eine forensische Prüfung rechtfertigen. Entscheidend ist, ob auf ihnen PHP vor dem 21.10. ungepatcht und aus dem Netz erreichbar war. Dann konnte der Einstieg über die Webanwendung erfolgt sein, bevor der Kernel-Schutz überhaupt eine Rolle spielte, und ein später eingespielter Kernel-Patch räumt eine bereits abgelegte Webshell nicht auf. Sinnvoll ist, die Logs aus dem fraglichen Zeitraum zu sichten, insbesondere Webserver- und Systemprotokolle, und auffällige Zugriffe oder unerwartete Dateien mit der Sicherheitsabteilung zu klären.
Wo ein Neustart nicht möglich war und die Module gesperrt wurden, bleibt die Sperre bis zum Neustart die einzige Absicherung. Wer mehrere Server betreibt, sollte nach Exposition sortieren: zuerst Systeme mit PHP-Anwendungen im Internet, dann solche mit mehreren lokalen Konten, zuletzt isolierte Rechner. Auch diese Priorisierung ist eine dm-Einordnung.
