Am 28. Oktober 2026 hat die US-Cybersicherheitsbehörde CISA zwei Schwachstellen in ihren Katalog der nachweislich ausgenutzten Sicherheitslücken (Known Exploited Vulnerabilities, kurz KEV) aufgenommen: Fragnesia im Linux-Kernel (CVE-2026-46300) und eine Protokollierungslücke in VMware ESX (CVE-2026-41709). Für beide gibt es seit Monaten Updates. Trotzdem werden sie in laufenden Angriffen eingesetzt, die Linux-Lücke sogar in Kombination mit PHP2Shell, über das wir vergangene Woche berichtet haben.

Warum das auch kleine und mittlere Betriebe angeht: VMware ESXi läuft in vielen Serverräumen des Mittelstands, und Linux steckt nicht nur in Webservern, sondern auch in Firewalls, Speichersystemen (NAS), Telefonanlagen und anderen Geräten, die selten jemand aktualisiert.

Für unsere Kunden vorab: Laufende ESXi-Hosts lösen wir bei unseren Kunden seit Jahren schrittweise ab und migrieren alle ESXi-Instanzen auf Proxmox. Diesen Umstieg übernehmen wir bei Bedarf auch für Betriebe, die bisher nicht von uns betreut werden.

Fragnesia: Vom Webshell zum Root-Zugriff in einer Viertelstunde

Fragnesia ist eine Lücke zur Rechteausweitung. Ein Angreifer braucht also zuerst einen Fuß in der Tür, etwa ein Webshell auf einem Server. Danach kann er über einen Fehler im IPsec-Teil des Kernels (ESP in TCP) Daten in den Seitencache schreiben, also in die Kopie von Dateien, die der Kernel im Arbeitsspeicher hält. Das funktioniert auch bei Dateien, die auf der Festplatte schreibgeschützt sind. Im beobachteten Angriff wurde so die Datei /etc/pam.d/su überschrieben, danach gelang su root ohne Passwort. Die Lücke ist mit CVSS 7,8 als hoch eingestuft und betrifft praktisch alle Kernel seit Version 3.9 aus dem Jahr 2013.

Öffentlich ist Fragnesia seit dem 13. Mai 2026, zusammen mit einem funktionierenden Exploit. Die Korrektur wurde Ende Mai in den Kernel aufgenommen, Microsoft hatte bereits Mitte Mai davor gewarnt. Die abgesicherten Kernel-Versionen sind 5.10.257, 5.15.208, 6.1.174, 6.6.141, 6.12.91, 6.18.33 und 7.0.10, die Distributionen haben die Korrektur in ihre eigenen Kernel übernommen.

Neu ist, was die Sicherheitsfirma Dream am 26. Oktober veröffentlicht hat: Ein mutmaßlich aus China gesteuerter Angreifer hat eine eigene PHP2Shell-Variante mit Fragnesia zu einer Kette verbunden. Eine einzige Anfrage ohne Anmeldung, und nach weniger als 15 Minuten lief ein Webshell mit Root-Rechten. So wurden 24 Firewalls und ein Verwaltungsserver in den USA, Japan, Taiwan und Südkorea übernommen, darunter zwei Geräte einer US-Behördenumgebung. Die betroffenen Firewalls liefen mit dem veralteten PHP 8.0.30. Vom Verwaltungsserver aus griff der Angreifer anschließend das Active Directory an. Dream nennt den Firewall-Hersteller nicht. Palo Alto Networks hat am 29. Oktober jedoch bestätigt, dass die PHP2Shell-Lücken gegen aus dem Internet erreichbare Verwaltungsoberflächen seiner PAN-OS-Firewalls aktiv ausgenutzt werden, und hat Hotfixes für alle unterstützten Versionen bis zum 30. Oktober angekündigt.

Eine Besonderheit sollten Administratoren kennen: Die Manipulation im Seitencache lebt nur im Arbeitsspeicher. Ein Neustart beseitigt sie, löscht aber auch die Spuren. Wer einen Einbruch vermutet, sollte deshalb erst Beweise sichern und dann neu starten.

VMware ESX: Eine „niedrige“ Lücke als Tarnkappe

Die zweite Schwachstelle wirkt auf den ersten Blick harmlos. CVE-2026-41709 hat einen CVSS-Wert von nur 2,7. Sie verschafft niemandem Zugang, sondern erlaubt es einem Administrator, auf einem ESX-Host bestimmte Befehle auszuführen, ohne dass sie im Protokoll auftauchen. Genau das macht sie für Angreifer wertvoll, die schon drin sind.

Laut dem am 28. Oktober veröffentlichten Bericht von CrowdStrike hat die China zugeordnete Gruppe WARP PANDA die Lücke bis Anfang 2026 als Zero-Day genutzt, also bevor Broadcom sie kannte. Ziel waren Unternehmen in den USA, darunter mehrere Anwaltskanzleien. Die Gruppe hinterlegte Schadsoftware in vCenter-Umgebungen und verwischte ihre Spuren auf den Hosts. Broadcom hat die Lücke am 29. Juli 2026 mit der Sicherheitsmitteilung VMSA-2026-0006 geschlossen, hält aber an der Einstufung „niedrig“ fest. heise security kritisiert das als zu harmlos.

Wichtig für die Praxis: Dieselbe Sicherheitsmitteilung schließt drei kritische Lücken mit CVSS-Werten bis 9,8, darunter eine Anmeldeumgehung in vCenter und einen Ausbruch aus einer virtuellen Maschine auf den Host. Wer die Updates vom Sommer noch nicht eingespielt hat, hat also gleich zwei Gründe, das nachzuholen. Abgesichert sind ESXi 8.0 Update 3j, ESXi 9.0.2.0100 und ESXi 9.1.0.0 sowie VMware Cloud Foundation 5.2.4. Für ESXi 7.0 gibt es seit dem 2. Oktober 2025 keinen allgemeinen Support mehr, Patches erhalten nur noch Kunden mit kostenpflichtigem Extended Support. Wer noch auf Version 7 läuft, sollte den Umstieg einplanen. Für Fragnesia hat CISA den US-Behörden eine Frist bis zum 31. Oktober gesetzt, für die ESX-Lücke bis zum 11. November 2026.

Die Lehre aus dem Fall: Protokolle, die nur auf dem Hypervisor selbst liegen, sind keine verlässliche Grundlage. Wer seine Logs laufend an ein zentrales System weiterleitet, bemerkt es auch, wenn sie plötzlich ausbleiben.

Was Sie jetzt prüfen sollten

  1. Linux-Server: Kernel-Stand kontrollieren und auf eine abgesicherte Version aktualisieren. Das Update allein reicht nicht, der Server muss neu gestartet werden, sonst läuft der alte Kernel weiter. Ausnahme sind Systeme mit Live-Patching.
  2. Geräte mit Linux im Inneren: Firewall, NAS, Telefonanlage, Videorekorder, Druckserver. Hier hilft nur die Firmware des Herstellers. Prüfen Sie, ob es Sicherheitshinweise gibt, und sorgen Sie dafür, dass Verwaltungsoberflächen nie direkt aus dem Internet erreichbar sind.
  3. VMware ESXi und vCenter: Build-Nummer der Hosts mit den oben genannten Versionen vergleichen. Auch vCenter muss auf den Stand von VMSA-2026-0006. Für ESXi 7 den Wechsel auf Version 8 oder 9 planen.
  4. PHP: Die Einstiegstür für die beschriebene Angriffskette war PHP2Shell. Was dazu zu tun ist, steht in unserem Beitrag zur PHP-Sicherheitslücke.
  5. Zentrale Protokollierung: Logs von Hypervisoren, Firewalls und Servern an einen separaten Syslog-Server oder ein SIEM weiterleiten und einen Alarm einrichten, wenn ein Logstrom abreißt.
  6. Bei Verdacht nicht blind neu starten: Unbekannte PHP-Dateien im Webverzeichnis, neue systemd-Dienste, Einträge in rc.local, veränderte Dateien unter /etc/pam.d/ oder ausgehende SSH-Verbindungen sind Warnzeichen. Dann zuerst Beweise sichern und Hilfe holen.
  7. Für Administratoren als Übergangslösung: Wird kein IPsec benötigt, lässt sich das Laden der Kernel-Module esp4 und esp6 sperren. Damit ist der verwundbare Codepfad nicht erreichbar. Das ersetzt das Update nicht, verschafft aber Zeit bis zum nächsten Wartungsfenster.

Wer kümmert sich bei Ihnen darum?

Beide Lücken waren seit Monaten geschlossen, bevor die Angriffe begannen. Betroffen sind Systeme, bei denen niemand regelmäßig nachsieht. Genau dafür gibt es unsere Betreuung für Virtualisierung und Server: Updates, Überwachung und Wartungsfenster zu festen Terminen, ab 129 €* pro Server und Monat. Wer seine Logs bisher nur lokal sammelt, bekommt von uns ein zentrales Protokollsystem eingerichtet.

Sie sind unsicher, ob Ihre Systeme betroffen sind?

Wir prüfen das gern für Sie, auch wenn Sie bisher nicht von uns betreut werden. Rufen Sie uns an unter 07724 82902-0 oder schreiben Sie uns über das Kontaktformular. Einen breiteren Blick auf Ihre IT gibt unser IT-Sicherheits-Check.

Quellen: CISA, KEV-Meldung vom 28.10.2026 · CVE-2026-46300 (kernel.org) · CVE-2026-41709 (Broadcom) · Broadcom, VMSA-2026-0006 (29.07.2026, Rev. 2 vom 19.08.2026) · CrowdStrike, 2026 Legal Threat Landscape Report (28.10.2026) · Dream, Chained PHP2Shell Exploit Roots 25 Servers (26.10.2026) · Microsoft Security Blog, Dirty Frag mit Nachtrag zu Fragnesia (14.05.2026) · Palo Alto Networks, Advisory zu CVE-2026-109618 (Stand 29.10.2026) · NVISO, PHP2Shell Operational Guidance (23.10.2026) · heise security, 29.10.2026

* Alle Preise netto zzgl. der jeweils gültigen gesetzlichen Mehrwertsteuer.

KI-Hinweis: Dieser Beitrag wurde mit Unterstützung von KI verfasst und von der virtual gaps UG redaktionell geprüft.