Eine kritische Schwachstelle im Linux-Kernel kann Angreifern den Ausbruch aus einer KVM-Gastmaschine auf das Host-System ermöglichen. Die als PwnEscape bezeichnete Lücke wird unter CVE-2026-99999 geführt und erreicht einen CVSS-Wert von 9,3. Als Auslöser genügen manipulierte IPv4-Pakete mit fehlerhaften Checksum-Metadaten.
Betroffen sind potenziell virtualisierte Linux-Umgebungen, in denen ein Angreifer bereits Code innerhalb einer Gast-VM ausführen kann und die vom Gast kontrollierten Metadaten den verwundbaren Netzwerkpfad des Hosts erreichen. Das ist keine aus der Ferne und ohne Zugang ausnutzbare Netzwerklücke. Für Cloud- und Plattformbetreiber bleibt sie dennoch gravierend: Der Angriff setzt genau dort an, wo die Trennung zwischen nicht vertrauenswürdigem Gast und privilegiertem Host halten muss.
Die operative Besonderheit liegt außerhalb des eigentlichen KVM-Hypervisors. Fehlerhaft ist der IPv4-Netzwerk-Stack des Host-Kernels. Deshalb behebt ein aktualisierter Kernel innerhalb der Gastmaschine das Problem nicht. Entscheidend ist der Patch-Stand des Hosts.
Validierte Pakete können nachträglich verändert werden
Linux-Pakete können Metadaten mitführen, die festlegen, wo eine Prüfsummenberechnung beginnt und an welcher Stelle das Ergebnis geschrieben werden soll. Diese Technik wird unter anderem für Checksum-Offloading verwendet. Nach den veröffentlichten Analysen kann ein Gast jedoch manipulierte Metadaten liefern, die später im Host verarbeitet werden.
Wie PwnEscape die Grenze zwischen Gast und Host angreift
Die Grafik zeigt den Angriffspfad von einer kontrollierten Gast-VM über manipulierte IPv4-Checksum-Metadaten bis zu den möglichen Auswirkungen auf den Linux-Host.
Die problematische Funktion skb_checksum_help kann dadurch einen bereits geprüften Netzwerk-Header korrumpieren. Sicherheitsprüfungen arbeiten dann mit einer anderen Darstellung des Pakets als nachgelagerte Teile des Netzwerk-Stacks. Der Kernel hat auf bestimmte Felder bereits vertraut und gehandelt, bevor diese nachträglich überschrieben werden.
Damit entsteht mehr als ein gewöhnlicher Fehler bei der Paketverarbeitung. Forscher Paulos Yibelo beschreibt den Mechanismus als neue Angriffsklasse: Nicht zwingend der Paketinhalt selbst, sondern weniger vertrauenswürdige Metadaten verändern sicherheitsrelevante Felder nach der Validierung. PwnEscape wurde im Rahmen einer mit einer Million US-Dollar dotierten Sandbox-Sicherheits-Challenge von Vercel entdeckt und am 15. Oktober 2026 öffentlich gemacht.
Informationsleck belegt, Host-Codeausführung im Labor gezeigt
Die möglichen Auswirkungen reichen laut Red Hat von der Offenlegung sensibler Host-Speicherbereiche über Systemabstürze und Denial of Service bis zu beliebiger Codeausführung auf dem Host. Ein Speicherleck wurde nach den vorliegenden Angaben in Vercel-Produktions-Sandboxes nachgewiesen. Die Codeausführung auf dem Host wurde in einer Laborumgebung demonstriert.
Diese Nachweise sind von einer beobachteten Angriffswelle zu unterscheiden. Mit Stand vom 19. Oktober 2026 gibt es keine öffentlichen Belege für eine böswillige Ausnutzung in realen Angriffen. CVE-2026-99999 steht auch nicht im Katalog der nachweislich ausgenutzten Schwachstellen der US-Behörde CISA. Die Veröffentlichungen belegen technische Ausnutzbarkeit, aber nicht, dass derzeit ein öffentlich verfügbarer Exploit breit eingesetzt wird.
Der Angriff benötigt zudem lokale Rechte innerhalb einer Gast-VM. Ein Angreifer muss dort Code ausführen und manipulierte Pakete erzeugen können. Das begrenzt den Kreis möglicher Angreifer, ist bei Hosting-Plattformen, CI-Systemen, Sandbox-Diensten und anderen Angeboten mit fremden Workloads aber Teil des normalen Bedrohungsmodells.
Der fehlerhafte Code reicht bis Linux 2.6.27 zurück
Die Schwachstelle betrifft Kernel-Versionen ab Linux 2.6.27 und war damit ungefähr 18 Jahre lang im Code vorhanden. Ein Upstream-Fix von Red-Hat-Entwickler Michael S. Tsirkin trägt die Commit-ID 6785011f8b16. Er wurde am 8. Oktober 2026 in den Networking-Tree und am 14. Oktober in den Mainline-Kernel übernommen.
Als gepatcht gelten unter anderem die stabilen Kernel-Versionen 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 und 7.2.11 sowie 7.3-rc7. Die Versionsnummer des Distributionskernels allein ist allerdings nicht immer ausreichend, weil Anbieter Sicherheitskorrekturen häufig in ältere Kernel zurückportieren. Betreiber sollten deshalb die jeweilige CVE-Meldung ihrer Distribution und die konkrete Paketversion prüfen.
Red Hat führt RHEL 8, 9 und 10 als betroffen. Auch AlmaLinux 8, 9 und 10 sind betroffen; gepatchte Kernel lagen zum Berichtszeitpunkt bereits in den Test-Repositories. Bis korrigierte Pakete regulär ausgeliefert und auf den Hosts aktiviert sind, bleibt zwischen verfügbarem Upstream-Patch und tatsächlich geschützter Infrastruktur eine operative Lücke.
Cloud-Nutzung bedeutet nicht automatisch Betroffenheit
Nicht jede KVM-basierte Cloud ist gleichermaßen exponiert. AWS bewertet EC2 als nicht gefährdet. Google Cloud gilt aufgrund seiner konkreten KVM-Implementierung wahrscheinlich ebenfalls als geschützt. Für Kunden verwalteter Clouds ist deshalb das Sicherheitsbulletin des Anbieters wichtiger als die bloße Feststellung, dass irgendwo KVM verwendet wird.
Anders liegt der Fall bei selbst betriebenen Virtualisierungsclustern und Produkten, die auf KVM und Linux-Hosts aufbauen. Dort müssen Verantwortliche den Kernel des physischen Hosts beziehungsweise der Virtualisierungs-Appliance prüfen. Das betrifft potenziell auch Plattformen wie Proxmox oder Nutanix, wobei deren eigene Advisories und Updatepakete maßgeblich sind.
Priorität hat die Inventarisierung aller KVM-Hosts mit nicht vertrauenswürdigen oder unterschiedlich privilegierten Gästen. Anschließend sollten Betreiber verfügbare Hersteller-Updates einspielen und sicherstellen, dass der korrigierte Kernel tatsächlich läuft – üblicherweise nach einem Neustart oder über ein vom Anbieter unterstütztes Live-Patching-Verfahren. Wo noch kein Fix verfügbar ist, sollte geprüft werden, ob fremde Workloads vorübergehend auf geschützte Hosts verschoben oder ihre Ausführung eingeschränkt werden müssen.
Die Isolationsgrenze reicht über den Hypervisor hinaus
PwnEscape ist vor allem deshalb relevant, weil die Lücke nicht im klassischen KVM-Kern steckt. Eine Gastmaschine interagiert über virtuelle Geräte, Netzwerkpfade und optimierte Kernel-Schnittstellen mit weit mehr Host-Code als nur mit dem Virtual Machine Monitor. Jede dieser Komponenten wird Teil der Isolationsgrenze, sobald sie Daten oder Metadaten aus einem nicht vertrauenswürdigen Gast verarbeitet.
Für Betreiber folgt daraus eine nüchterne Konsequenz: Der Sicherheitszustand einer Virtualisierungsplattform lässt sich nicht allein an der KVM-Version ablesen. Entscheidend sind Host-Kernel, Paketpfad, Anbieterimplementierung und der tatsächlich aktivierte Patch. Bei PwnEscape liegt der Fix deshalb nicht dort, wo die sichtbar betroffene Anwendung läuft, sondern eine Ebene darunter.
Jens analysiert seit Jahren digitale Märkte, Preisbewegungen und Plattform-Strategien. Als Betreiber mehrerer datengetriebener Systeme wertet er täglich große Mengen an Produkt- und Trenddaten aus. Sein Fokus liegt auf Einordnung statt Hype: Was bedeutet eine Entwicklung wirklich für Nutzer, Preise und Märkte?
