PwnEscape trifft KVM-Hosts, und der Kernel entscheidet

Ja, Sie sollten Ihre Proxmox- und KVM-Hosts auf den Fix prüfen, und zwar den Kernel des Hosts, nicht den der VM. Laut CVE-Record CVE-2026-99999 sind Linux-Kernel ab 2.6.27 betroffen; fehlerfrei sind 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57, 7.2.11 und Linux 7.3. Wirksam wird ein Update erst nach einem Neustart des Hosts mit dem neuen Kernel, und nur dort, wo Ihre Distribution den Backport schon ausliefert.

Was PwnEscape ist und wen es betrifft

PwnEscape ist der Name für eine Schwachstelle im IPv4-Netzwerkcode des Linux-Kernels, entdeckt von Paulos Yibelo (pwn.ai). Der zugehörige Commit heißt „ipv4: validate checksum_start before completing checksum“. Pakete mit fehlerhaften Checksummen-Metadaten können demnach den Netzwerk-Header beschädigen. Die Linux-CNA (die Vergabestelle für Linux-CVEs) bezeichnet den Fix selbst als „defence in depth“ und schreibt, eine umfassendere Prüfung beim Paketeingang sei in Arbeit.

Das Angriffsszenario laut CVE-Record: Eine nicht vertrauenswürdige VM, etwa eine microVM, schickt über ihr virtio-net-Interface präparierte Frames. virtio-net ist die paravirtualisierte Netzwerkkarte des Gastes. Der Host reicht diese Frames über sein TAP-Gerät, eine virtuelle Netzwerkschnittstelle im Kernel, in den IPv4-Stack. Der Record betont ausdrücklich, dass es sich nicht um einen Empfangspfad aus dem Internet handelt.

Betroffen sind damit Hosts, auf denen fremde oder wenig vertrauenswürdige Gäste laufen: Hosting-Angebote, Sandbox-Plattformen, geteilte Labore. dm-Einordnung: Wer nur eigene, gut gepflegte VMs betreibt, hat ein geringeres Risiko, braucht den Kernel-Stand aber trotzdem im Blick. Der Gast-Kernel ist nicht die Stelle, an der der Fehler korrigiert wird.

Welche Kernel-Version ist fehlerfrei?

Der CVE-Record nennt je Kernel-Reihe den ersten fehlerfreien Stand. Wer einen Longterm-Kernel einsetzt, braucht mindestens die Version seiner Reihe:

• 5.10.272 und 5.15.223
• 6.1.190, 6.6.159 und 6.12.113
• 6.18.57
• 7.2.11 sowie Linux 7.3

Bei Distributionskerneln zählt nicht die Versionsnummer allein, denn Hersteller übernehmen Korrekturen oft per Backport in ältere Basisversionen. Maßgeblich ist dann das Advisory der Distribution. Linux 7.3, seit dem 18. Oktober Mainline, enthält den Fix von Haus aus.

Welcher Kernel auf Ihrem Host aktuell läuft, zeigt uname -r. Nach einem Paket-Update meldet der Befehl erst nach dem Neustart den neuen Stand, denn bis dahin läuft weiter der alte Kernel im Speicher.

Stand bei Debian, Ubuntu, Red Hat und Proxmox

Die Lage unterscheidet sich je Distribution deutlich. Nach den am 20.10.2026 abgerufenen Advisories gilt:

• Debian: Laut Debian Security Tracker ist bookworm-security mit 6.1.190-1 (DLA-4841-1) und trixie-security mit 6.12.113-1 (DSA-6568-1) behoben; forky/sid hat 7.2.11-1.
• Ubuntu: Alle Releases stehen auf „Needs evaluation“, die Priorität ist Medium. Ein Fix ist dort noch nicht gelistet.
• Red Hat: Laut Red Hat sind alle Produktströme „affected“, die Fixes sind in Arbeit. Eine Mitigation, die Red Hats Kriterien erfüllt, gibt es nicht.
• Proxmox: Für Proxmox liegt kein geprüftes Advisory vor, hier gilt nur der Hinweis, dass der Backport läuft. The Register hofft auf einen Fix in Produkten wie Proxmox und Nutanix; der Backport läuft, eine Proxmox-Kernel-Version ist nicht belegt.

Wer Debian-Stable-Hosts betreibt, kann also schon aktualisieren. Bei Ubuntu und Red Hat bleibt vorerst das Warten auf das Advisory. Proxmox-Nutzende sollten die Kernel-Pakete des Projekts beobachten, statt auf den Debian-Kernel zu schließen; dm-Einordnung: Proxmox liefert einen eigenen Kernel aus.

Backports und Versionsnummern bei Distributionskernen

Die Debian-Stände zeigen, warum ein Blick auf die Hauptversion nicht genügt: Debian 12 „bookworm“ liefert den Fix mit 6.1.190-1, Debian 13 „trixie“ mit 6.12.113-1, die Entwicklungszweige forky/sid mit 7.2.11-1. Distributionen übernehmen Korrekturen häufig in ihre eigene Kernel-Linie, statt auf eine neuere Upstream-Version zu springen. Maßgeblich ist deshalb die Paketversion laut Advisory, nicht allein die Zahl, die uname -r zeigt.

Die beiden Debian-Kennungen unterscheiden sich im Zweig. Laut Debian Security Tracker läuft bookworm unter DLA-4841-1, trixie unter DSA-6568-1. DSA steht für Debian Security Advisory und betrifft die aktuell regulär betreute Veröffentlichung. DLA steht für Debian LTS Advisory und gehört zur Langzeitpflege älterer Releases. Dass beide Zweige bereits ein Update haben, heißt: Wer Debian-Hosts betreibt, kann den Fix einspielen, ohne auf weitere Meldungen zu warten.

dm-Einordnung: Bei Ubuntu steht die CVE in allen Releases auf „Needs evaluation“ mit Priorität Medium. Das ist keine Entwarnung, sondern ein offener Bearbeitungsstand, der sich ändern kann. Red Hat führt alle Produktströme als „affected“, Fixes sind in Arbeit.

Wie kritisch ist die Lücke wirklich?

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptSystem administrator at night in a server room typing on a laptop connected to a rack server, monitors with abstract terminal-like patterns, focused mood. Photorealistic editorial magazine photo, 16:9. Absolutely no text, no letters, no numbers, no logos, no brand marks.

Die Bewertungen liegen auseinander. Laut The Register steht die Lücke bei 9.3 (Critical), Red Hat stuft mit 8.8 niedriger ein. Eine eigene Analyse der NVD liegt nicht vor, der Status lautet „Received“.

Zur Ausnutzung: Die CISA-Einstufung (SSVC, 16.10.) lautet bei „exploitation“ auf „none“, und im CISA-KEV-Katalog steht die CVE nach Stand vom 16.10. nicht. Red Hat erwähnt einen „KEV active-exploit case“, ein Beleg für aktive Angriffe ergibt sich daraus nicht. Bestätigte Ausnutzung in freier Wildbahn ist damit nicht belegt, was kein Beweis des Gegenteils ist. Für Kernel-Lücken im KEV-Katalog der CISA gelten für US-Bundesbehörden feste Patch-Fristen; PwnEscape gehört derzeit nicht dazu.

Was die Einstufungen im Einzelnen bedeuten

CVSS ist ein Punkteschema für die technische Schwere einer Lücke, nicht für die Wahrscheinlichkeit eines Angriffs. Die 9.3 nennt The Register; Red Hat bewertet dieselbe Lücke für die eigenen Produkte mit 8.8 (Important). dm-Einordnung: Der Unterschied dürfte daraus entstehen, dass Hersteller Annahmen zur eigenen Konfiguration einrechnen; Red Hat begründet die 8.8 nicht. Für die Priorisierung zählt, ob Ihre Hosts nicht vertrauenswürdige VMs ausführen.

Die CISA-Auswertung nach SSVC (Stakeholder-Specific Vulnerability Categorization) vom 16.10.2026 steht bei Ausnutzung auf „none“. Im KEV-Katalog (Known Exploited Vulnerabilities) der CISA war die CVE zum Stand 16.10. nicht verzeichnet. Eine aktive Ausnutzung ist damit nicht belegt. Der NVD-Status „Received“ besagt lediglich, dass die US-Schwachstellendatenbank den Eintrag erhalten, aber noch nicht selbst analysiert hat; eine eigene NVD-Bewertung fehlt.

Red Hat nennt keine Mitigation, weil keine die eigenen Kriterien erfüllt. Ein Workaround steht also nicht zur Verfügung, und der Kernel-Fix bleibt der Weg. Der Record bezeichnet den Fix als „defence in depth“ und kündigt eine vollständigere Prüfung der Eingangsdaten an; weitere Änderungen sind daher möglich.

Woher der Fund stammt

Laut pwn.ai-Forschungsbericht entstand der Fund in der Vercel-Sandbox-Challenge. Anfangs ließen sich pro Durchlauf 32 Byte Host-Speicher auslesen; im eigenen Labor gelang dem Team ein vollständiger Ausbruch aus der VM. Vercel schreibt im Blog: „No reports showed anyone accessing customer data in Vercel Sandbox.“

Gilt das auch für Cloud-Instanzen?

Das hängt vom Anbieter ab. The Register zitiert AWS, wonach EC2 nicht gefährdet sei, und Google Cloud halte sich für „probably“ nicht betroffen. Beides sind Herstellerangaben, und sie gelten für diese Plattformen, nicht für Cloud-Angebote insgesamt. Zu kleineren Anbietern, die KVM auf Standard-Linux-Kerneln betreiben, liegt keine Aussage vor.

Als Mieterin oder Mieter einer VM können Sie am Host nichts patchen. Sie können beim Anbieter nachfragen, ob dessen Hosts den Fix haben. Das ist eine dm-Einordnung, kein belegter Standardweg.

Neustart planen: Live-Migration und Wartungsfenster

dm-Einordnung aus der Betriebspraxis: Ein Kernel-Update auf dem Host verlangt einen Neustart, und der betrifft alle Gäste darauf. In einem Cluster lassen sich VMs vorher per Live-Migration auf andere Knoten verschieben, sodass sie weiterlaufen. Das setzt voraus, dass die anderen Knoten Kapazität haben und den gleichen Netz- und Speicherzugang bieten. Einzelne Hosts ohne Cluster brauchen ein Wartungsfenster mit kurzer Downtime.

Eine dm-Einordnung zur Reihenfolge: Zuerst die Hosts aktualisieren, auf denen fremde Gäste laufen, dann interne. Rollende Neustarts je Knoten halten die Ausfallzeit klein. Einen Workaround gibt es laut Red Hat nicht, das Warten auf den Backport ersetzt kein Patchen. Wer in der Zwischenzeit nur vertrauenswürdige Gäste auf dem Host betreibt, verkleinert die Angriffsfläche, ohne die Lücke zu schließen.

Die nächste Entscheidung

Prüfen Sie auf jedem Host mit uname -r den laufenden Kernel und gleichen Sie ihn mit der Fix-Liste oben ab. Unter Debian bookworm oder trixie spielen Sie das Kernel-Update ein und starten neu. Unter Ubuntu, Red Hat und Proxmox bleibt vorerst nur das Warten auf das jeweilige Advisory; dm-Einordnung: Prüfen Sie die Advisory-Seiten regelmäßig, bis ein Fix gelistet ist. Erst danach ist die Lücke auf dem Host geschlossen, nicht schon nach dem Download des Pakets.