Leipzig, 7. November 2026 – In den Serverräumen und Leitstellen ist gerade einiges los: Die Linux-Kernel-Lücke CVE-2026-46300, in der Sicherheitsforschung „Fragnesia“ genannt, steht seit dem 28. Oktober im CISA-Katalog der aktiv ausgenutzten Schwachstellen. Sekundärquellen bewerten sie mit CVSS 7,8, also als hoch. CISA führt sie nüchterner als „Linux Kernel Missing Initialization of a Variable Vulnerability“.

Direkt aus dem Internet lässt sich damit nicht automatisch jeder Linux-Server übernehmen. Zunächst braucht ein Angreifer Codeausführung mit eingeschränkten Rechten auf dem System. Genau hier wird die Sache unangenehm: In Verbindung mit den PHP2Shell-Lücken CVE-2026-109618 und CVE-2026-109619, die jeweils mit CVSS 9,2 bewertet werden, kann aus einem Webserver-Einbruch eine Root-Kette werden. Eine Webshell läuft zunächst typischerweise mit den Rechten des Webserver-Benutzers. Fragnesia kann diese Rechte unter geeigneten Bedingungen bis auf root ausweiten.

Vom Webserver bis zur vollständigen Kontrolle

PHP2Shell bezeichnet eine unauthentifizierte Remote-Code-Ausführung mit anschließender Ablage einer PHP-Webshell. Die betroffenen PHP-Versionen sind in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 behoben. Ein PHP-Update beseitigt allerdings keine bereits installierte Webshell und ersetzt auch keine Untersuchung eines möglichen Einbruchs.

Die Kernel-Lücke sitzt laut Berichten im XFRM-Subsystem für ESP-in-TCP. Technisch wird die Ursache in der Kernel-Funktion skb_try_coalesce() im Netzwerkcode vermutet. Fragnesia wird der Dirty-Frag-Klasse zugeordnet: Bei der fehlerhaften Behandlung geteilter Speicherfragmente kann eine verlorene Kennzeichnung dazu führen, dass eigentlich geschützte, nur lesbare Daten nachträglich verändert werden. Eine Manipulation des Page-Cache kann sogar laufende Programme verändern, ohne die zugehörige Datei auf der Festplatte anzutasten.

Nach erfolgreicher Kernel-Ausnutzung könnten Angreifer Konten anlegen, Software installieren, weitere Server ansteuern, Systemeinstellungen ändern oder den gesamten Host kontrollieren. Für Shared-Hosting-Anbieter ist das besonders heikel, weil ein Root-Zugriff mehrere Kundensysteme auf einem Rechner betreffen kann. Anbieter Linux-basierter Appliances müssen Sicherheitsupdates womöglich schneller ausliefern.

Hier könnte Ihr Advertorial stehen
Ein Advertorial bietet Unternehmen die Möglichkeit, ihre Botschaft direkt im redaktionellen Umfeld zu platzieren

Ob Fragnesia neben PHP2Shell bei den abgeschalteten Verwaltungsportalen in Nordrhein-Westfalen eingesetzt wurde, ist nicht belegt. Dream Security soll die Angriffskette gegen bis zu 25 Server verwendet haben, darunter drei im Umfeld einer US-Regierungsorganisation; unabhängig bestätigt sind diese Angaben nicht. Auch die Zuordnung zu einem mutmaßlich China-nahen Akteur bleibt unbelegt. Die dokumentierten Angriffe zielten laut Berichten auf Firewalls und Management-Server.

168 Tage zwischen Fix und KEV-Eintrag

Öffentlich bekannt wurde Fragnesia am 13. Mai 2026, zugleich wurde die Lücke im Kernel behoben. Am 25. Oktober veröffentlichte Ostorlab einen Bericht zur PHP2Shell-Angriffswelle. Drei Tage später nahm CISA CVE-2026-46300 in den KEV-Katalog auf, am 29. Oktober verwies die Behörde auf die Kombination mit PHP2Shell; BleepingComputer und CSO Online berichteten darüber. Am 30. Oktober aktualisierte CISA den Eintrag. Zwischen dem Kernel-Fix und der Aufnahme lagen 168 Tage.

Für US-Bundesbehörden wurde meist der 31. Oktober als Frist genannt, ein Bericht nannte abweichend den 10. November. Die Frist gilt im Rahmen der US-Richtlinie und nicht automatisch für private deutsche Betreiber. Aus der KEV-Aufnahme lassen sich weder Opferzahlen noch eine allgemeine Angriffswelle gegen deutsche Server oder Proxmox-Systeme ableiten. Eine Aufnahme in den Katalog bedeutet auch nicht, dass jeder Server kompromittiert wurde. Am 3. November beschrieb Kaspersky PHP2Shell einschließlich der Fragnesia-Kette als aktiv ausgenutzt.

Unklar bleiben der von CISA selbst ausgewiesene CVSS-Wert, die genaue technische Einstufung gegenüber der CISA-Formulierung, die verbindliche US-Frist, die tatsächliche Zahl der Opfer sowie die Lage in Deutschland, Österreich und der Schweiz. Als mögliche weitere Entwicklungen gelten zusätzliche Kombinationen von Fragnesia mit anderen Web-Einstiegen, detailliertere Hinweise der Distributionen, forensische Datensicherung vor Patch-Neustarts, kürzere Kernel-Update-Zyklen bei Hostern und anhaltende Verwechslungen zwischen Spitznamen und offiziellen CVE- beziehungsweise CISA-Bezeichnungen.

Welcher Kernel läuft wirklich?

Als behoben gelten laut den ausgewerteten Berichten die Upstream-Zweige 5.10 ab 5.10.257, 5.15 ab 5.15.208, 6.1 ab 6.1.174, 6.6 ab 6.6.141, 6.12 ab 6.12.91, 6.18 ab 6.18.33 und 7.0 ab 7.0.10. Im Mainline-Zweig ist der Fix ab 7.1 enthalten. Der Fehler soll seit Kernel 3.9 im Code vorhanden sein.

Die Versionsnummer allein ist aber ein schlechter Kompass. Distributionen können Sicherheitskorrekturen zurückportieren und dabei ihre eigenen Versionsnummern beibehalten. Entscheidend sind deshalb die Sicherheitsbulletins und Changelogs der jeweiligen Distribution. Zu Debian und AlmaLinux wurden Sicherheitsupdates gemeldet; eine vollständige, unabhängig bestätigte Herstellermatrix lag laut Artikel nicht vor.

Canonical nennt unter anderem folgende korrigierte Standardpakete: Ubuntu 24.04 LTS mit 6.8.0-124.124, Ubuntu 22.04 LTS mit 5.15.0-181.191 und Ubuntu 26.04 LTS mit 7.0.0-22.22. HWE-, Cloud- und OEM-Kernel haben eigene Paketstände, manche Varianten gelten laut Hersteller als nicht betroffen. Das tatsächlich laufende Kernel-Image muss daher zur verwendeten Variante passen. Ein installiertes, neueres Paket schützt erst nach dem Start dieses Kernels.

Unter Linux helfen vor einem Neustart etwa diese Prüfungen:

uname -r
php -v
sudo find /var/www -type f -name '*.php' -mtime -14 -ls
sudo ss -tupn
ps auxf

Distribution und laufenden Kernel zeigt zusätzlich:

uname -r
cat /etc/os-release

Unter Debian oder Ubuntu lassen sich verfügbare Aktualisierungen mit folgenden Befehlen prüfen:

sudo apt update
apt list --upgradable

Für die Installation stehen beispielhaft diese Befehle:

sudo apt update
sudo apt full-upgrade
sudo dnf upgrade --refresh kernel
sudo reboot
uname -r

Vor der Installation sollten Backups und Wartungsarbeiten geplant werden. Neustarts bei ZFS, verschlüsselten Datenträgern, virtuellen Maschinen oder Fernzugriffen gehören gezielt vorbereitet, nicht zwischen Tür und Angel erledigt.

Proxmox, Container und flüchtige Spuren

Bei Proxmox nutzt der physische Host einen eigenen Kernel. LXC-Container verwenden dagegen den Kernel des Proxmox-Hosts; vollvirtualisierte VMs besitzen jeweils einen eigenen Gast-Kernel. Host und VMs müssen also getrennt geprüft werden. Ein Kernel-Update im LXC-Container ersetzt nicht die Aktualisierung des Proxmox-Hosts. Auch Docker-Container teilen den Kernel des Hosts – ein aktuelles PHP-Image schützt nicht vor einem verwundbaren Host-Kernel.

Auf einem Proxmox-System liefern uname -r und pveversion -v die ersten Anhaltspunkte:

uname -r
pveversion -v

Danach sollte geprüft werden, ob das aktivierte Proxmox-Repository ein korrigiertes Kernel-Paket bereitstellt. Vor dem Neustart braucht es Konsolenzugang, ein Backup und bei Clustern einen Wartungsplan. Nach Installation und Neustart wird der tatsächlich laufende Kernel erneut kontrolliert. Netzwerk, Storage, VMs, Container und wichtige Anwendungen gehören anschließend getestet.

Canonicals dokumentierte Übergangsmaßnahmen für ESP/IPsec-Module können in bestimmten Situationen helfen, ersetzen aber nicht den Sicherheitsfix. Das Deaktivieren solcher Module kann VPNs und andere Netzwerkfunktionen