Am 19. Oktober 2026 meldet The Register: Die Lücke CVE-2026-99999, von ihrem Entdecker Paulos Yibelo „PwnEscape“ getauft, wird mit 9,3 auf der CVSS-Skala bewertet und ermöglicht es einer Gast-VM, über wenige fehlerhafte IPv4-Pakete die Isolation zum Host zu durchbrechen. Gefunden wurde die Lücke im Rahmen einer von Vercel ausgerufenen Million-Dollar-Challenge, die am 18. August 2026 gestartet wurde.

Für einen Betrieb, der auf KVM-basierter Virtualisierung läuft – Proxmox, Nutanix, eine eigene Cloud – ist das kein theoretisches Szenario. Die Isolation zwischen Gast-VM und Host ist die Grundlage, auf der alle anderen Sicherheitsmaßnahmen aufbauen. In der Praxis bedeutet das: Ein kompromittiertes Testsystem, eine schlecht isolierte Entwicklungsumgebung oder ein Gast, der von einem externen Dienstleister betrieben wird, kann zum Einstiegspunkt in das gesamte System werden. Der Host-Crash, den die Forscher in ihren Tests beobachteten, würde alle Co-located Workloads gleichzeitig stoppen.

Die Lücke im Detail

Das Problem sitzt nicht in KVM selbst, sondern im Linux-Netzwerk-Stack – genauer in der Checksum-Offload-Mechanik. Linux erlaubt es, dass ein Paket mit dem Zustand CHECKSUM_PARTIAL durch den Stack wandert: Die Checksumme wird nicht sofort berechnet, sondern erst später, wenn das Paket die Fragmentierungs- oder Ausgabe-Phase erreicht. Dabei schreibt die Funktion skb_checksum_help() das Ergebnis an eine Position, die durch die Felder csum_start und csum_offset im sk_buff bestimmt wird.

Der Haken: Diese Metadaten stammen aus dem Gast und kreuzen damit eine Vertrauensgrenze. In der fehlerhaften Abfolge in ip_do_fragment() wurde die Checksumme vor dem Abruf des IPv4-Header-Pointers abgeschlossen. Eine manipulierte csum_start-Position ließ die Schreiboperation in den bereits validierten IPv4-Header überschreiben. Im Forschungsbeispiel änderte sich das IHL-Feld von 20 auf 60 Bytes – der Rest des Stack glaubte, ein 60-Byte-Header vor sich zu haben, und kopierte dabei 32 Bytes Host-Speicher, die als IPv4-Options nach außen liefen.

Michael S. Tsirkin von Red Hat fasst es im Linux-Kernel-Stable-Tree so zusammen: „If a packet with bad checksum metadata gets into the ipv4 stack, skb_checksum_help can corrupt the network header and cause a bunch of mischief.“ – Wenn ein Paket mit fehlerhaften Checksum-Metadaten in den IPv4-Stack gelangt, kann skb_checksum_help den Netzwerk-Header beschädigen und für allerlei Unheil sorgen. Die technische Aufarbeitung auf pwn.ai und die Zusammenfassung auf OSS-Security belegen, dass die Lücke eine neue Angriffsklasse darstellt: Unvertraute Checksum-Metadaten schreiben sicherheitsrelevante Paketfelder um, nachdem der Kernel bereits auf der Basis des ursprünglichen Headers entschieden hat.

Der Fix liegt upstream als Commit 6785011f8b16 („ipv4: validate checksum_start before completing checksum“) vor. Er prüft in fünf IPv4-Checksum-Abschlussroutinen, ob csum_start hinter dem Ende des IPv4-Headers liegt, und verwirft ungültige Daten. Betroffene Kernel-Versionen, für die Patches verfügbar sind: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57, 7.2.11 und Mainline 7.3-rc7. Laut dev.to stand Amazon Linux am 18. Oktober 2026 noch auf „Pending Fix“; Red Hat hatte zum selben Zeitpunkt keine allgemeinen Mitigationsmaßnahmen veröffentlicht.

Was jetzt zu tun ist

1. Prüfen, welche Kernel-Version auf den Host-Systemen läuft, und diese mit der obigen Liste abgleichen. Läuft ein Kernel unterhalb der genannten Versionen, ist ein Update auf die gepatchte Variante erforderlich. Wichtig: Das Update betrifft den Host-Kernel, nicht den Gast. Ein Guest-Update behebt die Lücke nicht.
2. Nach dem Update verifizieren, dass der Commit 6785011f8b16 im laufenden Kernel enthalten ist. Bei Distro-Paketen heißt das: Die Changelog-Einträge der Kernel-Pakete prüfen oder den Distro-Support nachfragen, ob der Backport ausgeliefert wurde. Bei Proxmox und Nutanix die jeweiligen Release-Notes ab 18. Oktober 2026 durchsehen.
3. Bestandsaufnahme der Gast-VMs: Welche laufen unvertraute oder extern betreute Workloads? Solange der Patch noch nicht aufgespielt ist, diese VMs isolieren oder pausieren. Ein Host-Crash trifft alle Co-located Workloads gleichzeitig – wer das Risiko nicht tragen will, nimmt die VM kurzzeitig offline.

Das Ärgerliche an Lücken dieser Art: Man merkt sie nicht am Bildschirm, nicht in der Anwendung, nicht im Log. Die 32 Bytes, die in den Forschungsbeispielen nach außen liefen, sahen aus wie normale IPv4-Options. Wer jetzt unsicher ist, ob die eigene Virtualisierungslandschaft sauber gepatcht ist, hat damit schon die richtige Frage gestellt. Wir schauen uns das gern konkret an – von der Kernel-Version auf dem Host bis zur Frage, welche VMs überhaupt unvertraute Pakete verarbeiten. Hier geht es zum Kontakt.

Beitragsbild: panumas nikhomkhai auf Pexels