Die von Paulos Yibelo und dem Forschungsteam von pwn.ai dokumentierte Schwachstelle PwnEscape zeigt, dass diese Isolation auch durch Fehler außerhalb des eigentlichen Hypervisors durchbrochen werden kann.
Die Ursache liegt nicht unmittelbar im KVM-Virtualisierungscode, sondern in der Verarbeitung von IPv4-Netzwerkpaketen durch den Linux-Kernel.
Damit betrifft die Sicherheitsfrage potenziell verschiedene Virtualisierungs- und Sandbox-Architekturen, sofern sie verwundbare Kernelpfade über geeignete virtuelle Netzwerkgeräte erreichbar machen.
Wie funktioniert CVE-2026-99999?
Ausgangspunkt ist eine Funktion zur Berechnung von Netzwerk-Prüfsummen, das sogenannte Checksum Offloading.
Linux kann die Prüfsummenberechnung bei der Verarbeitung von Netzwerkpaketen zunächst zurückstellen. Dafür werden Metadaten gespeichert, die beschreiben, an welcher Stelle die Prüfsumme später berechnet und in das Paket geschrieben werden soll.
Genau diese Metadaten ließen sich im untersuchten Angriffspfad so beeinflussen, dass die spätere Berechnung einen bereits überprüften IPv4-Header veränderte.
Der Kernel traf somit Sicherheitsentscheidungen auf Grundlage eines zunächst gültigen Paketheaders. Anschließend wurde dieser Header verändert, bevor ihn ein weiterer Verarbeitungsschritt erneut verwendete.
Aus 20 Byte werden plötzlich 60 Byte
Eine zentrale Rolle spielt das IPv4-Feld Internet Header Length (IHL). Dieses legt fest, wie lang der IP-Header ist.
Ein gewöhnlicher IPv4-Header umfasst 20 Byte. Durch die manipulierte Prüfsummenoperation konnte die Längenangabe im dokumentierten Versuchsaufbau nachträglich auf 60 Byte verändert werden.
Der Kernel interpretierte daraufhin zusätzliche Speicherbereiche als Bestandteil des IP-Headers, obwohl diese ursprünglich nicht zu den gültigen linearen Paketdaten gehörten.
Im untersuchten Fall standen 28 Byte gültige lineare Paketdaten einer späteren Verarbeitung von 60 Byte gegenüber. Die Differenz von 32 Byte konnte Informationen aus dem Speicher des Hosts offenlegen.
Diese Daten wurden bei der Fragmentierung als vermeintliche IPv4-Optionen in ausgehende Netzwerkpakete übernommen.
Damit entstand ein tatsächlich beobachtbarer Host-Speicherabfluss und nicht lediglich eine theoretische Überschreitung von Puffergrenzen.
Von einem Speicherleck zum vollständigen KVM-Ausbruch
Ein Speicherleck allein ist noch kein vollständiger Ausbruch aus einer virtuellen Maschine. Die Forscher entwickelten den Angriff jedoch weiter.
Durch wiederholte Speicherbeobachtungen und gezielte Beeinflussung von Kernel-Speicherstrukturen gelang es ihnen nach eigenen Angaben, ausgewählte Schreiboperationen in den Speicher des Hosts auszuführen.
In ihrer eigenen KVM-Testumgebung führte dies schließlich zur Ausführung eines Programms mit Root-Rechten auf dem Host-Betriebssystem.
Die Angriffskette konnte bei vier unabhängigen Kaltstarts reproduziert werden.
Zusätzlich dokumentierten die Forscher einen möglichen Absturz des Hosts. Bei einem gemeinsam genutzten Virtualisierungsserver könnte ein solcher Ausfall auch andere virtuelle Maschinen beeinträchtigen.
Wichtig: Die vollständige Host-Kompromittierung wurde in einer kontrollierten Forschungsumgebung demonstriert. Daraus folgt nicht, dass ein entsprechender Root-Angriff bereits bei Cloud-Anbietern in deren Produktivumgebungen stattgefunden hat.
Vercels Millionen-Challenge brachte die Lücke ans Licht
Ausgangspunkt der Untersuchung war eine Sicherheitschallenge von Vercel, die am 18. August 2026 angekündigt wurde.
Das Unternehmen stellte einen gesamten möglichen Prämienpool von einer Million US-Dollar bereit, um die Sicherheit seines Sandbox-Produkts untersuchen zu lassen.
Die Herausforderung richtete sich ausdrücklich auch an Forscher, die einen Ausbruch aus isolierten virtuellen Maschinen nachweisen konnten.
Im Abschlussbericht der Challenge dokumentierte Vercel insgesamt 1.285 eingereichte Berichte. Davon wurden 57 als gültig eingestuft. Lediglich eine Schwachstelle erhielt die Bewertung Critical.
Diese kritische Entdeckung war der Linux-Kernel-Fehler, der als PwnEscape bekannt wurde.
Vercel bestätigte einen Host-Speicherabfluss in produktiven Sandbox-Umgebungen. Das Unternehmen erklärte zugleich, dass kein Bericht einen Zugriff auf Kundendateien, Geheimnisse oder Anwendungsdaten anderer Kunden nachgewiesen habe.
Die Forscher und beteiligten Unternehmen arbeiteten anschließend mit Linux-Kernel-Entwicklern an einer koordinierten Behebung.
Proxmox: Sicherheitsmeldung und Kernel-Fix
Für Betreiber von Proxmox VE ist die Sicherheitslücke besonders relevant, weil Proxmox auf Linux und KVM als zentralen Bestandteilen seiner Virtualisierungsplattform aufbaut.
Proxmox veröffentlichte am 16. Oktober 2026 die Sicherheitsmeldung PSA-2026-00068-1.
Als korrigiertes Kernelpaket für einen betroffenen Kernelzweig wird proxmox-kernel-7.0.14-24-pve genannt.
Die Versionsangabe ist nicht pauschal auf sämtliche Proxmox-Versionen übertragbar. Betreiber müssen prüfen, welcher Kernelzweig eingesetzt wird und ob dafür entsprechende Sicherheitskorrekturen verfügbar sind.
Was Administratoren jetzt prüfen sollten
- Aktuell gestartete Kernelversion mit
uname -r kontrollieren.
- Verfügbare Kernel- und Sicherheitsupdates prüfen.
- Herstellerinformationen für die verwendete Proxmox- oder Linux-Version berücksichtigen.
- Korrigierte Kernelpakete installieren.
- Den Host nach dem Update kontrolliert neu starten und die tatsächlich geladene Kernelversion erneut überprüfen.
Ein Update innerhalb der virtuellen Maschinen allein beseitigt keine Schwachstelle im Host-Kernel.
Linux-Kernel-Patch seit dem 14. Oktober 2026
Der akzeptierte Linux-Fix trägt den Titel ipv4: validate checksum_start before completing checksum und ist unter der Commit-Kennung 6785011f8b16 dokumentiert.
Der Patch ergänzt eine Prüfung, bevor der Kernel ausstehende Prüfsummenberechnungen ausführt.
Dadurch wird kontrolliert, ob der Beginn der Prüfsummenberechnung hinter dem gültigen IPv4-Header liegt. Eine nachträgliche Veränderung sicherheitsrelevanter Headerfelder durch diesen Mechanismus soll damit verhindert werden.
Die Änderung wurde am 8. Oktober 2026 in den Netzwerkentwicklungszweig aufgenommen und am 14. Oktober in den Hauptentwicklungszweig des Linux-Kernels übernommen.
Die Entwickler bezeichnen die Korrektur ausdrücklich als zusätzliche Absicherung. Weitere Prüfungen eingehender Prüfsummen-Metadaten bleiben ein eigenständiges Thema.
Der Upstream-Patch ist im Linux-Quellcode dokumentiert.
GPT-5.6 Sol half bei der Entdeckung der Sicherheitslücke
Die zweite bemerkenswerte Geschichte hinter PwnEscape betrifft den Einsatz künstlicher Intelligenz.
Für ihre Untersuchungen verwendeten die Forscher ein experimentelles Forschungssystem namens Omega-Pwn.
Dieses verbindet automatisierte Quellcodeanalysen mit längerfristigen Forschungsabläufen, der Speicherung früherer Ergebnisse und der parallelen Untersuchung verschiedener Angriffshypothesen.
Nach Angaben des Forschungsteams war GPT-5.6 Sol das zentrale Sprachmodell für die Analyse.
Die KI half dabei, Quellcode zu untersuchen, ungewöhnliche Verarbeitungspfade zu erkennen und mögliche Sicherheitsverletzungen in komplexen Kernel-Funktionen zu bewerten.
Die menschlichen Forscher definierten weiterhin die Forschungsfragen, überprüften Ergebnisse und entwickelten die konkreten Angriffsnachweise.
Weniger als 700 Dollar für KI-API-Token
Besonders auffällig ist die Kostenangabe: Laut pwn.ai wurden für die eingesetzten KI-API-Token weniger als 700 US-Dollar ausgegeben.
Bereits drei Tage nach dem Beginn der Challenge lag ein erster Nachweis des Host-Speicherabflusses vor.
Die genannten API-Kosten sind jedoch nicht mit den gesamten Forschungskosten gleichzusetzen. Menschliche Arbeitszeit, Testinfrastruktur und das erforderliche Spezialwissen sind darin nicht enthalten.
Dennoch zeigt PwnEscape, wie KI-Systeme die Analyse komplexer Software und die Suche nach bisher unbekannten Schwachstellen erheblich unterstützen können.
Warum PwnEscape für KI-Agenten und Cloud-Sandboxes relevant ist
Mit dem zunehmenden Einsatz autonomer KI-Agenten wächst auch die Zahl der Umgebungen, in denen automatisch erzeugter Code ausgeführt wird.
KI-Coding-Dienste, Entwicklungsplattformen und automatisierte Agentensysteme benötigen dafür sichere Ausführungsumgebungen.
Häufig kommen virtuelle Maschinen oder besonders abgeschottete MicroVMs zum Einsatz.
Die grundlegende Annahme lautet: Selbst wenn ein Programm innerhalb der Sandbox kompromittiert wird, darf es das darunterliegende Host-System nicht übernehmen.
PwnEscape demonstriert, dass diese Sicherheitsgrenze nicht ausschließlich vom Hypervisor abhängt.
Auch Betriebssystemkomponenten wie der Netzwerkstack und die Verarbeitung virtueller Netzwerkgeräte können entscheidende Angriffspunkte darstellen.
Der Fall bedeutet allerdings nicht, dass jede Linux-VM automatisch ausgenutzt werden kann. Entscheidend sind unter anderem die verwendete Kernelversion, die Netzwerkkonfiguration und die Erreichbarkeit des verwundbaren Verarbeitungspfads.
FAQ: Häufige Fragen zu PwnEscape
Was ist PwnEscape?
PwnEscape ist der Name einer kritischen Linux-Kernel-Schwachstelle mit der Kennung CVE-2026-99999. Sie ermöglicht unter bestimmten Voraussetzungen einen Speicherabfluss vom Host und kann als Grundlage für einen Ausbruch aus einer virtuellen Maschine dienen.
Ist Proxmox von CVE-2026-99999 betroffen?
Proxmox hat eine eigene Sicherheitsmeldung veröffentlicht und einen korrigierten Kernel für einen Kernelzweig genannt. Ob ein konkreter Proxmox-Server betroffen ist, hängt von seinem Kernel- und Patchstand ab.
Kann ein Angreifer damit Root auf dem Host erhalten?
Die Forscher demonstrierten Root-Codeausführung in einer eigenen KVM-Testumgebung. Ein entsprechender erfolgreicher Angriff auf produktive Kundenhosts wurde dadurch nicht nachgewiesen.
Sind alle KVM-Server verwundbar?
Nein. Die Schwachstelle liegt im Linux-Netzwerkstack. Eine praktische Ausnutzung hängt davon ab, ob der verwundbare Kernelpfad für einen Angreifer erreichbar ist. Bereits korrigierte Kernel enthalten entsprechende Schutzmaßnahmen.
Hat eine KI die Sicherheitslücke selbstständig entdeckt?
Nein. Die Entdeckung erfolgte durch ein menschlich geleitetes Forschungsteam, das GPT-5.6 Sol innerhalb seines Omega-Pwn-Systems für Analyse- und Forschungsaufgaben einsetzte.
Fazit: Eine neue Warnung für die Virtualisierungssicherheit
PwnEscape zeigt, dass eine Sicherheitslücke in einer vermeintlich alltäglichen Kernel-Funktion ausreichen kann, um die Isolationsgrenze einer virtuellen Maschine zu gefährden.
Der Angriff begann bei manipulierten Prüfsummen-Metadaten im Linux-Netzwerkstack, führte zu einem nachgewiesenen Host-Speicherabfluss und endete in der Forschungsumgebung mit Root-Codeausführung auf dem Host.
Gleichzeitig ist der Fall ein eindrucksvolles Beispiel für KI-gestützte Sicherheitsforschung. Mit GPT-5.6 Sol als Analysewerkzeug gelang es spezialisierten Forschern, innerhalb weniger Tage einen Fehler mit weitreichenden Folgen zu identifizieren.
Für Betreiber von Proxmox, KVM und anderen Linux-basierten Virtualisierungssystemen gilt deshalb: Den Host-Kernel prüfen, Sicherheitsupdates installieren und die Wirksamkeit des Updates nach einem Neustart kontrollieren.
Quellen
