Am 15. Oktober 2026 ist die kritische Schwachstelle CVE-2026-99999 veröffentlicht worden, die unter dem Namen PwnEscape kursiert. Sie liegt im Netzwerkcode des Linux-Kernels und ermöglicht es Code innerhalb einer VM, den Speicher des Hosts auszulesen, den Host zum Absturz zu bringen und dort Code auszuführen. The Hacker News berichtet, dass der Effekt in den Produktions-Sandboxes von Vercel nachgewiesen und vom Anbieter bestätigt wurde.

Für einen Betrieb, der Virtualisierung einsetzt – sei es KVM, eine Container-Plattform oder eine Cloud, die auf Linux-Kernel-Isolation setzt –, ist das ein konkretes Problem. Die Lücke betrifft nicht die Hypervisor-Schicht selbst, sondern den Netzwerkcode, den der Host-Kernel für alle Gäste ausführt. Wer Code in einer VM ausführt – als Entwickler, als Sandbox für Kundenanfragen oder als isolierte Testumgebung –, muss damit rechnen, dass die Isolation zur Host-Ebene hin reißen kann. Im schlechtesten Fall liest ein Prozess im Gast fortlaufend Host-Speicher aus, bringt den gesamten Host zum Absturz und nimmt damit alle darauf laufenden VMs mit. Ein externer Angreifer, der nur Pakete über das offene Internet schickt, kann die Lücke nicht ausnutzen – der Angriffstyp ist als local klassifiziert. Aber wer einmal Code im Gast hat, hat damit die Tür auf.

Was im Kernel konkret schiefgeht

Die Ursache liegt im sogenannten Checksum-Offload-Mechanismus. Der Kernel kann ein Paket in einem Zustand weitergeben, in dem die Prüfsumme noch ausstehend ist – er merkt sich über die Felder csum_start und csum_offset, wo später das Ergebnis hingeschrieben werden soll. Das Problem: Diese Metadaten stammen aus einer weniger vertrauenswürdigen Quelle, dem Gast, und autorisieren dennoch einen Schreibzugriff auf den Paket-Speicher. pwn.ai beschreibt den Mechanismus im Detail: Der Kernel validiert den IPv4-Header, trifft Routing- und Fragmentierungsentscheidungen auf Basis eines 20-Byte-Headers. Erst danach, bei der Fragmentierung in ip_do_fragment(), wird die ausstehende Prüfsumme abgeschlossen. Die Schreibposition kann dabei in den bereits geparsten IPv4-Header fallen und dessen IHL-Feld verändern. In den Labor-Tests änderte sich der erste Byte-Wert von 0x45 (IHL 5, also 20 Bytes) auf 0x4f (IHL 15, also 60 Bytes), ohne dass die Versionsnibble sich veränderte. Der Kernel las den Header dann neu ein und sah eine 60-Byte-Struktur, auf der er nie Entscheidungen getroffen hatte. Pro Paket konnten so rund 32 Bytes Host-Speicher ausgelesen werden; zwei speziell konstruierte Pakete reichten, um den Host zum Absturz zu bringen.

Der Fix ist ein einzelner Commit: 6785011f8b16, geschrieben von Michael S. Tsirkin (Red Hat) und in den Mainline-Kernel übernommen. Er fügt eine Prüfung hinzu, die sicherstellt, dass die Prüfsummen-Schreibposition nicht in den IPv4-Header fallen kann, und setzt diese an fünf Stellen im Netzwerkcode um. Der Autor bezeichnet die Änderung selbst als „defence in depth measure" und vermerkt, dass eine vollständigere Absicherung des Paket-Eingangswegs noch aussteht. IT Boltwise listet die ersten fixierten Versionen in den Stable-Branches: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 und 7.2.11. Distributionen pflegen eigene Kernel-Forks und bauen den Patch oft ein, ohne die Versionsnummer zu ändern. Die Versionszahl aus uname reicht daher nicht – entscheidend ist, ob der Patch in dem tatsächlich laufenden Kernel-Build enthalten ist.

Was jetzt zu tun ist

1. Prüfen, ob der Host-Kernel – nicht der Guest-Kernel – eine der genannten fixierten Versionen enthält. Bei Distributionen: das Security-Advisory des Anbieters konsultieren und den Kernel-Build gegen den Patch abgleichen, nicht nur die Versionsnummer lesen.
2. Den Host-Kernel auf die fixierte Version oder den Vendor-Build mit dem Patch aktualisieren und den Host neu starten. Ein Update nur des Gast-Kernels schließt die Lücke nicht, weil der fehlerhafte Pfad auf der Host-Seite liegt.
3. Falls ein Update kurzfristig nicht möglich ist: Nested Virtualization deaktivieren und sicherstellen, dass VM-Prozesse nur die minimal benötigten Rechte erhalten (bei Firecracker: Jailer aktivieren). Das beseitigt die Lücke nicht, begrenzt aber das Schadensausmaß.

Das Ärgerliche an dieser Lücke: Man merkt sie erst, wenn jemand schon im Gast sitzt und gezielt Pakete schickt. Bis dahin läuft alles munter weiter, und die Isolation wirkt stabil – bis sie es nicht mehr ist. Wer unsicher ist, ob der eigene Host-Kernel den Patch tatsächlich enthält oder ob die VM-Konfiguration so steht, dass ein Gast so wenig wie möglich erreicht, hat damit schon die richtige Frage gestellt. Wir schauen uns das gerne einmal konkret an: Host-Kernel, VM-Betrieb, Netzwerkpfade – hier erreichen Sie uns, wenn Sie das Thema einmal durchgehen wollen.

Beitragsbild: panumas nikhomkhai auf Pexels