Im IPv4-Code des Linux-Kernels steckt eine Schwachstelle, die die Grenze zwischen Gast und Host einreißt: PwnEscape (CVE-2026-99999) erlaubt es Code aus einer virtuellen Maschine heraus, Speicher des Host-Kernels zu lesen – nachgewiesen gegen Produktions-Sandboxes. Speziell gestaltete IPv4-Pakete reichen dafür aus. Bewertet wird die Lücke mit CVSS 9,3; der CVE-Record der Kernel-Maintainer führt sie als Critical. Betroffen sind Hosts mit KVM und virtio-Netzwerk, also praktisch jede Multi-Tenant-Virtualisierung; ein Fix ist seit dem 14. Oktober im Mainline-Kernel. Hinweise auf reale Ausnutzung fehlen.
PwnEscape: Der Fehler sitzt im Netzwerk-Stack des Host-Kernels
Wer bei VM-Escape an QEMU oder KVM denkt, liegt hier falsch. Der Fehler liegt im IPv4-Code des Host-Kernels: Der Host vertraut den Checksum-Offload-Metadaten, die ein Gast über ein virtio-Netzwerkgerät übergibt, und prüft sie nicht gegen den IPv4-Header. Die zurückgestellte Checksum-Operation schreibt dadurch in einen Header, der bereits verarbeitet wurde. Im Demonstrationsexempel springt das Längenfeld von 5 auf 15, sodass die IP-Fragmentierung einen 20-Byte-Header als 60 Byte behandelt.
Praktisch heißt das: Pro manipuliertem Paket wandern rund 32 Byte Host-Kernel-Speicher in den Gast, und der Gast gibt das Tempo vor – solange er sendet, läuft der Leak weiter. Der Fehler steckt seit rund 18 Jahren im Kernel; gemeldet wurde er am 4. September privat an den Kernel-Security-Kontakt und die Networking-Maintainer.
Was in Produktion belegt ist – und was nur im Labor
Für die Dringlichkeit ist die Trennung entscheidend. Gegen die Produktions-Sandboxes von Vercel ließ sich der Speicher-Leak wiederholt auslösen, und zwar aus einer Standard-Sandbox heraus, ohne Spezialzugriff. Host-Crash und Code-Ausführung als root hat Paulos Yibelo von pwn.ai dagegen nur auf eigenen Maschinen mit KVM und Firecracker gezeigt: Zwei präparierte Pakete genügten, um den Host abstürzen zu lassen – samt aller VMs darauf. Separate Schreibzugriffe in Host-Kernel-Speicher ließen sich zu einem Programm verketten, das als root auf dem Host läuft.
Yibelo selbst schränkt genau das ein: Es sei „not a claim of root command execution in any vendor’s production environment". Wer die Lücke als bewiesenen Root-Einbruch in Cloud-Umgebungen verkauft, überzieht die Faktenlage. Gefunden wurde sie im Rahmen der „$1 Million Sandbox Challenge" von Vercel im August 2026 – aus 1.285 Reports, 242.000 US-Dollar ausgeschütteten Prämien und einer höchsten Einzelprämie von 50.000 US-Dollar ging genau ein Critical-Finding hervor: PwnEscape.
CVSS 9,3: hoher Score für eine lokale Lücke
Im CVE-Record ist der Angriffsvektor als „local" geführt. Voraussetzung ist bereits laufender Code im Gast – wer von außen auf einen Webserver zielt, kommt so nicht weiter. In der KEV-Liste von CISA taucht PwnEscape bislang nicht auf, Hinweise auf reale Ausnutzung gibt es nicht.
Trotzdem ist der Score nicht aus der Luft gegriffen: Für Cloud-Hoster, Sandbox-Anbieter und jede Umgebung, in der fremder Code in VMs läuft, ist die Gast-Host-Grenze die eigentliche Sicherheitszone. Wer sie überschreitet, liest potenziell Secrets anderer Mandanten oder reißt den kompletten Host in den Absturz – ein Denial-of-Service, den ein einzelner Mieter auslösen kann. Einschränkend bleibt: Die 9,3 stammen aus dem CVE-Record der Kernel-Maintainer; der NVD-Eintrag war zum Recherchezeitpunkt vorhanden, eine eigene Prüfung stand aber noch aus. Eine unabhängige Nachbewertung fehlt damit. Formulierungen wie „Zero-Day" oder „Gain Root Access", die in einigen Überschriften kursieren, deckt die Faktenlage ebenfalls nicht: Die Lücke wurde privat gemeldet, ist gepatcht, und die Root-Ausführung ist ein Laborergebnis.
Patch-Status: Fix im Mainline-Kernel, Backports in Stable
Der Fix ist Commit 6785011f8b16 von Michael S. Tsirkin (Red Hat). Er steckt seit dem 14. Oktober im Mainline-Kernel und wurde in die Stable-Branches zurückportiert. Für AlmaLinux stehen seit dem 16. Oktober gepatchte Kernel im Testing-Repository bereit. Einen Workaround gibt es nach derzeitigem Stand nicht – der Weg führt über das Kernel-Update.
Fazit: Patch-Priorität nach Einsatzszenario
Für Hosts, die KVM mit virtio-Netzwerk und fremden Gast-Code betreiben, ist das Update dringend: Die Lücke erlaubt einen wiederholbaren Speicher-Leak über die Mandantengrenze, und ohne Workaround bleibt nur der Kernel-Patch. Cloud- und Sandbox-Anbieter sollten die gefixten Kernel aus den Stable-Branches bzw. aus dem Testing-Repository der Distribution einspielen und den Rollout auf allen Host-Knoten priorisieren.
Weniger dringend ist die Lage für Einzelplatz-Rechner ohne laufende VMs: Ohne Code im Gast greift die Lücke nicht. Der lokale Vektor und die fehlende KEV-Listung ändern aber nichts daran, dass die Gast-Host-Grenze in virtualisierten Umgebungen die eigentliche Sicherheitszone bleibt – und dass PwnEscape mit einem Labor-Root-Exploit zeigt, wie dünn diese Grenze ist. Bis unabhängige Bestätigungen und eine NVD-Bewertung vorliegen, bleibt die 9,3 die beste verfügbare Einschätzung. Updates gehören auf den Wartungsplan; in Multi-Tenant-Umgebungen nach vorn.
Quellen
- Critical PwnEscape Linux Kernel Vulnerability Lets Guest VMs Read Host Memory – The Hacker News
- linux kernel: PwnEscape: Guest-to-Host KVM Escape (CVE-2026-99999) – oss-security
- PwnEscape (CVE-2026-99999): Patched kernels available in testing – AlmaLinux Blog
- PwnEscape: vulnerabilidad crítica en Linux permite escapar de máquinas virtuales y controlar hosts – Segu-Info
- PwnEscape: Linux-Lücke lässt Angreifer aus VMs ausbrechen – Golem Security