CVE-2026-99999: PwnEscape lässt Gast-VMs Host-Speicher lesen

Eine als PwnEscape bezeichnete Schwachstelle im Linux-Kernel erlaubt es einem Prozess in einer Gast-VM, wiederholt Speicher des Host-Kernels auszulesen. Sie läuft als CVE-2026-99999 mit einem CVSS-Score von 9,3 und dem Attack Vector „local". Betroffen sind virtualisierte Umgebungen, in denen nicht vollständig vertrauenswürdige Gäste auf gemeinsamer Hardware laufen — Cloud-Hoster, Sandbox- und Container-Plattformen. Bestätigt ist der Speicher-Leak gegen Vercels Produktions-Sandboxes; Absturz und Codeausführung auf dem Host wurden bislang nur in der Laborumgebung des Forschers gezeigt. Ein Workaround wurde nicht veröffentlicht.

Was PwnEscape im IPv4-Stack des Linux-Kernels ausnutzt

Der Angriffspunkt liegt nicht in der Virtualisierungsschicht selbst, sondern im IPv4-Stack des Host-Kernels — ausdrücklich kein Fehler in KVM. Das Muster ist ein Zusammenspiel aus Deferred Checksum und Fragmentierung: Ein Gast kann Pakete so präparieren, dass der Kernel eine Prüfsumme über einen Header berechnet, dessen Länge sich von den üblichen 20 Byte auf 60 Byte verschiebt. Die Berechnung greift dann über den eigentlichen Paketpuffer hinaus und gibt Teile des angrenzenden Kernel-Speichers mit zurück — rund 32 Byte pro Paket, und das wiederholbar.

Weil jeder Durchlauf nur ein kleines Fenster öffnet, ist der Angriff kein einzelner Schlag, sondern eine Serie. Über viele Pakete lässt sich Speicher ausschnittsweise rekonstruieren. Die Entdecker sprechen von einer „entirely new class of attacks in Linux networking". Bemerkenswert ist das, weil Checksum-Offload seit Jahren als unspektakulärer Pfad im Netzwerk-Stack gilt und entsprechend wenig Aufmerksamkeit im Review bekommen haben dürfte. Dass der Fehler rund 18 Jahre unentdeckt blieb, passt zu dieser Einschätzung: Er geht auf den virtio-net-Header-Support für tun/tap aus dem Jahr 2008 und den Checksum-Offload für Packet Sockets aus 2010 zurück.

Bestätigt ist der Speicher-Leak, nicht die Codeausführung

Für die Bewertung entscheidend ist die Trennung der drei denkbaren Auswirkungen: Lesen von Host-Speicher, Absturz des Hosts, Codeausführung auf dem Host. Nur die erste ist außerhalb eines Labors belegt — und zwar gegen Vercels Produktions-Sandboxes. Crash und Codeausführung hat der Forscher bislang ausschließlich in seiner eigenen Testumgebung gezeigt. Wer PwnEscape als vollständigen, in freier Wildbahn ausgenutzten VM-Ausbruch darstellt, geht über den belegten Stand hinaus.

Hinzu kommt der Attack Vector „local": Ein Angreifer braucht bereits Codeausführung innerhalb der Gast-VM. PwnEscape ist damit in erster Linie ein Eskalationsweg für den zweiten Schritt — nach einer erfolgreichen Kompromittierung eines Containers oder einer Sandbox — und kein Einfallstor aus dem Netz. Genau das ist aber die realistische Bedrohung für mandantenfähige Plattformen: Wer Fremdcode in einer VM ausführt, kann versuchen, über den Speicher-Leak an Daten des Hypervisors oder benachbarter Gäste zu gelangen. Die Vertrauensgrenze, die solche Angebote tragen, steht damit zur Disposition.

Welche Kernel-Versionen betroffen sind und was der Fix leistet

Der Upstream-Commit 6785011f8b16 wurde am 14. Oktober 2026 in den Mainline-Zweig gemergt, die Meldung an die Kernel-Security- und Networking-Maintainer erfolgte bereits am 4. September 2026. Die Korrektur gilt als „defense in depth" — ein Hinweis darauf, dass der Patch die Fehlerklasse härter absichert, nicht zwingend jede denkbare Ausnutzung beweisbar ausschließt. Ein Workaround wurde nicht veröffentlicht.

Auf Distributionsebene ist der Stand uneinheitlich. Test-Kernel für AlmaLinux 8, 9 und 10 stehen bereit, der Entwicklungszweig 7.3-rc7 ist als gefixt geführt. RHEL 8, 9 und 10 gelten als betroffen, ein Fix ist noch nicht veröffentlicht. In der Breite der Kernel-Versionen, die als erstmals gefixt gelten, dürfte die Lage je nach Anbieter deutlich heterogener sein als bei klassischen CVE-Wellen: Angreifer in kompromittierten VMs könnten die darunterliegenden Hostsysteme erreichen.

Was Admins und Plattformbetreiber jetzt tun sollten

Ohne Workaround bleibt nur der Kernel-Patch. Priorisieren sollten ihn alle, die Hosts mit nicht vollständig vertrauenswürdigen Gästen betreiben — also Cloud-, Sandbox- und CI-Umgebungen vor klassischen Single-Tenant-Servern. Wer auf Distributions-Kernel mit verzögertem Fix angewiesen ist, muss die Isolation organisatorisch herstellen: getrennte Hardware für verschiedene Mandanten, kürzere Lebensdauern für Sandboxes, kein Mischen von vertrauenswürdigen und fremden Workloads auf demselben Host.

Sinnvoll ist außerdem ein Blick auf die Erkennung. Der Angriff erzeugt auffällige Fragmentierungsmuster aus einer Gast-VM heraus; ob das in der Praxis zuverlässig anschlägt, ist allerdings nicht belegt. Wer solche Muster sieht, sollte sie nicht als Fehlalarm abtun — der Fehler ist Teil einer neuartigen Lückenklasse im Netzwerkbereich von Linux, und Cloud-Hoster sind ausdrücklich mitbetroffen.

Bemerkenswert ist der Fund auch als Prozessfrage: Er entstand im Rahmen einer von Vercel ausgeschriebenen Sandbox-Challenge; die Ergebnisse sind öffentlich. Der Weg von der Meldung bis zum Mainline-Merge ist im ursprünglichen Disclosure-Thread dokumentiert, und die erstmals gefixten Kernel-Versionen sind in einer detaillierten technischen Aufarbeitung gelistet. Wer seine Plattform auf VM-Isolation stützt, sollte die Lücke zum Anlass nehmen, das eigene Vertrauensmodell zu prüfen: Die Hypervisor-Grenze war nie ein Sicherheitsversprechen, sondern eine Kosten-Nutzen-Abwägung — und diese Abwägung hat sich mit CVE-2026-99999 verschoben.

Quellen