PwnEscape CVE-2026-99999: Die Kunden-VM übernimmt den Host

Stand: 15.10.2026, 22:42 Uhr CEST. CVE-2026-99999 ist veröffentlicht, die Linux-CNA bewertet sie mit CVSS 3.1 9,3 / Critical. Upstream-Fixes sind benannt. Proxmox übernimmt den breiteren IPv4-Fix ab 7.0.14-24; 7.0.14-22 enthielt bereits einen vorläufigen Schutz für die Fragmentierung. Für mehrere Distributionen fehlen noch bestätigte Fixpakete. Der laufende Host-Kernel entscheidet.

Kurzfassung

• Worum es geht: PwnEscape nutzt fehlerhafte Prüfsummen-Metadaten aus einer virtuellen Netzwerkkarte. Der Linux-Kernel des Hosts kann dadurch bereits geprüfte Paketheader überschreiben und anschließend Speicher falsch verarbeiten.
• Was nachgewiesen wurde: Vercel bestätigt ein Host-Speicherleck aus produktiven Sandboxes. Host-Absturz und Codeausführung als Root wurden auf eigenen KVM- und Firecracker-Systemen des Forschers mit vergleichbarer Konfiguration demonstriert. Das ist keine Behauptung, jemand habe Root auf Vercels Produktionshosts erlangt.
• Kein Angriff allein aus dem Internet: Der dokumentierte Einstieg führt über eine kontrollierte VM beziehungsweise eine passende lokale virtuelle Netzwerkschnittstelle. Normale externe IPv4-Pakete transportieren diese internen Offload-Metadaten nicht.
• Kein Nested KVM nötig: Das Abschalten verschachtelter Virtualisierung hilft gegen diesen Netzwerkpfad nicht. Gerade für VPS-Hoster ist das unangenehm: Kunden dürfen ihre VMs und deren Betriebssystem ohnehin kontrollieren.
• Proxmox-Zielstand: Im 7.0-Zweig mindestens 7.0.14-24-pve booten oder einen neueren Stand mit diesem Backport. Für die geprüften 6.8-, 6.14- und 6.17-Zweige ist kein entsprechender Fix belegt.
• Nächster Schritt: Host-Kernel und virtuelles Netzwerk prüfen, verfügbaren Vendor-Fix einspielen und den Host neu starten. Ohne Fix gehören fremde Workloads auf bereits abgesicherte Nodes oder vorübergehend aus dem Betrieb.

Warum diese Lücke Hoster besonders trifft

Eine Kunden-VM darf kaputtgehen. Sie darf ihren eigenen Kernel ersetzen und als Root beliebigen Code ausführen. Was sie nicht darf: den Hypervisor-Host übernehmen und damit die anderen Kunden auf derselben Maschine gefährden.

PwnEscape greift genau diese Grenze an. Der Fehler sitzt dabei im Netzwerkstack von Linux, nicht in der CPU- oder Speicheremulation von KVM. Ein Update von QEMU, des Kundenimages oder der Proxmox-Weboberfläche allein repariert ihn deshalb nicht.

Vercels Bericht zur Sandbox-Challenge trennt die Ergebnisse ausdrücklich: Das Speicherleck wurde gegen produktive Sandboxes gezeigt. Die weitergehenden Angriffe liefen auf Systemen des Researchers. Laut Vercel gab es in der Challenge keinen Nachweis eines Zugriffs auf Kundendaten. Für Betreiber ist bereits ein wiederholbares Leck aus dem Host eine verletzte Mandantentrennung; ein kompletter Escape verschärft die Folgen erheblich.

Originalgrafik: pwn.ai, PwnEscape, Figure 1. Der Angriff passiert im Host-Netzwerkstack. Die Grafik zeigt den technischen Pfad, keine Aufnahme eines Angriffs auf einen Produktionshost.

Wie PwnEscape funktioniert

Die Prüfsumme wird später geschrieben

Linux berechnet Transport-Prüfsummen nicht immer sofort. Bei Checksum-Offload bekommt ein Paket zunächst den Status CHECKSUM_PARTIAL. Der interne Paketpuffer, ein sk_buff, merkt sich, wo die Berechnung beginnen und wo das Ergebnis landen soll. Später erledigt die Netzwerkkarte oder der Software-Helfer skb_checksum_help() die Arbeit.

Die Kernel-Dokumentation zu Checksum-Offload beschreibt dafür csum_start und csum_offset. Zusammen bestimmen sie eine Schreibposition im Paket. Das sind also keine bloßen Hinweise zur Performance: Der Host wird an dieser Stelle tatsächlich Bytes verändern.

Bei virtuellen Netzwerkkarten können solche Angaben vom Gast kommen. Im ursprünglichen Patchvorschlag beschreibt Paulos Yibelo den Fehler: Nach der Verarbeitung der Link-Layer-Header kann der angegebene Prüfsummenstart innerhalb des IPv4-Headers liegen. Eine Prüfung anhand der früheren Paketdarstellung reicht dann nicht mehr.

Ein geprüfter Header ändert nachträglich seine Bedeutung

Der Host hat das IPv4-Paket zu diesem Zeitpunkt bereits geparst und Routing-Entscheidungen getroffen. Muss er es später fragmentieren, vervollständigt er die ausstehende Prüfsumme. Die fehlerhaften Metadaten lenken diesen Schreibzugriff in den schon geprüften IP-Header.

Betroffen ist unter anderem IHL, das Feld für die IPv4-Headerlänge. Die Fragmentierung liest den veränderten Wert anschließend erneut und behandelt ihn als gültig. Der öffentliche Fragmentierungs-Patch beschreibt genau diese Reihenfolge: prüfen, durch einen späteren Schreibzugriff verändern, dann den veränderten Inhalt verwenden. Dafür braucht es kein Wettrennen zweier Threads.

Im Researcher-Beispiel werden aus 20 Byte IPv4-Header plötzlich vermeintliche 60 Byte. Der zusammenhängende gültige Paketbereich enthält aber nur 28 Byte. Die Differenz von 32 Byte liest der Fragmentierer aus Host-Speicher außerhalb der logischen Paketdaten und verschickt sie als angebliche IP-Optionen. Dafür muss der Lesezugriff nicht einmal die physisch reservierte Speicherallokation verlassen.

Originalgrafik: pwn.ai, PwnEscape, Figure 4. Die 32 Byte beziehen sich auf den gezeigten Versuchsaufbau, nicht auf eine allgemeine Obergrenze des Schadens.

Vom Speicherleck zum vollständigen Escape

Ein Speicherleck ist noch keine Root-Shell. pwn.ai berichtet zusätzlich von gezielten 64-Byte-Schreibzugriffen im Host-Kernel und einer daraus aufgebauten Kette bis zur Ausführung eines Helpers mit Host-Root. Diese Kette funktionierte laut Bericht über vier vollständige Kaltstarts der eigenen Testmaschine hinweg. Die Details dieses weiteren Exploit-Aufbaus sind für einen zweiten Teil angekündigt.

Der offizielle Linux-CVE-Datensatz bewertet das beschriebene MicroVM-Szenario mit AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. PR:N bedeutet hier insbesondere: keine Zugangsdaten oder administrativen Rechte auf dem Host erforderlich. Daraus folgt nicht, dass jeder gewöhnliche TCP-Client innerhalb eines beliebigen Gasts automatisch einen Escape auslösen kann. Entscheidend bleibt, ob der Angreifer die relevanten virtuellen Geräte-Metadaten beeinflussen und den betroffenen Host-Pfad erreichen kann.

Wann ein System angreifbar ist

Umgebung oder Voraussetzung	Einordnung
Ungepatchter Linux-Host mit vom Gast beeinflussbaren Offload-Metadaten	Der zentrale Prüffall. Virtio-Netzwerk über TAP oder vhost-net verdient besondere Aufmerksamkeit.
Host verarbeitet die Pakete in einem betroffenen IPv4-Pfad	Fragmentierung ist der veröffentlichte Ausgangspunkt. Der akzeptierte Fix schützt zusätzlich Bridge-Fragmentierung, NFQUEUE, das CHECKSUM-Target und Software-IPsec-Ausgabe.
Kunden können den Gast-Kernel oder virtuelle Geräte kontrollieren	Bei klassischen Root-VPS normal. Eine Beschränkung innerhalb des Kundenbetriebssystems ist deshalb kein verlässlicher Schutz des Hosts.
Nested Virtualization deaktiviert	Keine Entwarnung. PwnEscape benötigt diesen KVM-MMU-Pfad nicht.
Lokaler Prozess oder Container mit geeigneter TUN-/TAP-Schnittstelle	Ebenfalls prüfen. Der ursprüngliche Report nennt einen TUN-Pfad auch ohne VM. Gerätezugriff, Dateideskriptoren und Rechte sind entscheidend; nicht jeder Container ist automatisch ausnutzbar.
Gewöhnlicher Webserver ohne entsprechende lokale Angriffsfläche	Kein belegter Internet-zu-Root-Angriff durch normales Senden von Paketen. Den Kernel trotzdem über den Vendor aktualisieren.
Reines Bridging, andere virtuelle NIC oder deaktiviertes Offload	Kann den erreichbaren Pfad verändern. Das ist ohne Prüfung der gesamten Host-Verarbeitung kein belastbarer Fixnachweis.
Laufender Kernel mit dem passenden Fix oder nachgewiesenem Livepatch	Gegen die von diesem Fix adressierten IPv4-Pfade abgesichert. Ein lediglich installiertes Kernelpaket reicht nicht.

Der Fehler ist nicht auf den x86-KVM-Code begrenzt. Ein ARM-Host oder ein anderer Hypervisor-Name allein ist deshalb keine Entwarnung. Umgekehrt belegt der Linux-Bug keine pauschale Betroffenheit von ESXi, Hyper-V oder jedem beliebigen Cloud-Angebot. Maßgeblich ist die tatsächlich erreichte Linux-Netzwerkimplementierung.

Schlimmer als Januscape und Zapscape?

Für die mögliche Auswirkung gibt es wenig Spielraum: Host-Root kann bei allen drei Lücken die Trennung zwischen Kunden aufheben. Unterschiede liegen vor allem beim Einstieg und bei den öffentlich verfügbaren Exploit-Details.

Lücke	Entscheidender Unterschied für den Betrieb
Januscape	Greift KVMs x86-Shadow-MMU bei Nested Virtualization an. Nested KVM zu sperren ist hier eine relevante Maßnahme.
Zapscape	Ebenfalls ein Nested-KVM-/Shadow-MMU-Problem. Der veröffentlichte Exploit zeigt die Kette bis zur Host-Root-Ausführung, braucht aber eine passende Zielumgebung.
PwnEscape	Erreicht den Host über virtuelle Netzwerkverarbeitung. Nested KVM abzuschalten schließt diesen Einstieg nicht. Der erste Researcher-Artikel legt noch keine universell einsetzbare vollständige Escape-Kette offen.
Dirty Frag und Copy Fail	Lokale Kernel-Angriffe, besonders relevant für gemeinsam genutzte Hosts und Container. Die damaligen Modul- oder Socket-Sperren sind kein PwnEscape-Fix.

Unsere Einschätzung: PwnEscape ist für einen Hoster nicht pauschal harmloser. Wer Nested Virtualization nie angeboten hat, konnte damit einen wesentlichen Einstieg der beiden x86-Escapes vermeiden. PwnEscape muss dieser Betreiber trotzdem prüfen. Die noch nicht vollständig veröffentlichte Angriffskette begrenzt, was sich heute über einen Angriff auf beliebige Installationen sagen lässt. Sie ist kein Grund, einen verfügbaren Kernel-Fix liegenzulassen.

Patchstände nach Distribution

Die folgenden Angaben sind eine Momentaufnahme zum oben genannten Stand. „Kein Fix belegt“ bedeutet weder „nicht betroffen“ noch „es existiert sicher kein Patch“. Manche Hersteller haben die neue CVE noch nicht bewertet; ein Paket kann außerdem einen Backport enthalten, bevor die CVE im Changelog auftaucht.

Upstream Linux

Der Linux-CVE-Datensatz nennt den Fehler ab Linux 2.6.27 und diese gefixten Versionen innerhalb der jeweiligen Linie:

Kernel-Linie	Fix ab
5.10 LTS	5.10.272
5.15 LTS	5.15.223
6.1 LTS	6.1.190
6.6 LTS	6.6.159
6.12 LTS	6.12.113
6.18 LTS	6.18.57
7.2	7.2.11
Mainline	7.3-rc7

Der zentrale Commit heißt 6785011f8b16. Er prüft vor der Prüfsummenberechnung, ob deren Start hinter dem IPv4-Header liegt. Die zusätzliche Prüfung sitzt in fünf betroffenen Codepfaden. Die Commit-Beschreibung bezeichnet sie ausdrücklich als zusätzliche Absicherung; eine umfassendere Prüfung beim Paketeingang steht noch aus. Für einen produktiven Distributionskernel zählt dessen Backport, nicht ein Wechsel auf einen Mainline-Release-Candidate.

Distributionen und Hosting-Systeme

Distribution / Plattform	Verifizierter Stand und Konsequenz
Debian 12 / Bookworm	Der Security Tracker führt linux 6.1.176-1 und das Security-Paket 6.1.187-1 als verwundbar. Noch kein Debian-Fixstand eingetragen.
Debian 13 / Trixie	6.12.107-1 und trixie-security 6.12.111-1 stehen ebenfalls auf vulnerable. Upstream 6.12.113 ist nicht automatisch schon als Debian-Paket verfügbar.
Debian Forky / Sid	7.2.9-1 beziehungsweise 7.2.10-1 sind im Tracker verwundbar; der Eintrag steht auf unfixed. Für ältere Debian-/ELTS-Sonderzweige ist hier kein Fix nachgewiesen.
Ubuntu 22.04, 24.04 und 26.04 LTS	Der offizielle CVE-Tracker im Quellrepository führt die Standardkernel als needs-triage, noch ohne Fixversion. Das gilt auch für die geprüften AWS-, Azure-, GCP- und Oracle-Flavours. Canonicals vorläufige Priorität lautet medium; das ist keine Entwarnung für Hypervisor-Hosts.
Ubuntu Pro / ältere LTS / HWE	Auch für die geprüften älteren Basiskernel und mehrere HWE-Zweige steht die Bewertung noch aus. Flavour und Supportkanal einzeln prüfen; ignored bei einem ersetzten HWE-Zweig bedeutet nicht automatisch „sicher“.
RHEL 8 / 9 / 10, einschließlich RT und RHCOS	Zum Redaktionsstand konnten wir kein konkretes RHSA oder Fixpaket für diese CVE verifizieren. Keine Freigabe allein anhand einer neueren RHEL-Kernelnummer; Produktzweig über Red Hat beziehungsweise den Support abgleichen.
AlmaLinux 8 / 9 / 10	In den geprüften öffentlichen Quellen kein belastbarer Mindest-Fixstand gefunden. AlmaLinux-Errata gegen den eigenen Zweig prüfen; Fixnummern früherer Kernel-Lücken gelten hier nicht weiter.
Rocky Linux 8 / 9 / 10	Kein bestätigtes PwnEscape-Fixpaket in den geprüften Quellen. Maßgeblich sind die Rocky-Errata für den tatsächlich eingesetzten Zweig, gegebenenfalls ein gesondert dokumentierter Backport.
CloudLinux / KernelCare / Plesk	Kein konkreter PwnEscape-Fix oder passender Livepatch verifiziert. Eigene LVE-Kernel, übernommene Distributionskernel und Livepatch-Feeds getrennt prüfen. Ein Plesk-Update patcht den Host-Kernel nicht. CloudLinux-Sicherheitsmeldungen und aktiven Patchstatus heranziehen.
SUSE / openSUSE Leap / Tumbleweed	Kein produktspezifischer Mindest-Fixstand verifiziert; die CVE-Seite war beim Abruf noch nicht verfügbar. SUSE-Patchinformationen nach Produkt und Service Pack prüfen. Auch Tumbleweed braucht einen passenden Kernelstand oder Backport.
Oracle Linux, RHCK und UEK	Kein bestätigter ELSA-Fixstand gefunden. RHCK und UEK separat gegen die Oracle-CVE-Informationen prüfen. Ein Fix in einem Zweig erlaubt keine Aussage über den anderen.
Amazon Linux	AWS führt AL2023 mit kernel, kernel6.12 und kernel6.18 auf Pending Fix. Gleiches gilt im Tracker für AL2 Core und die Extras 5.4, 5.10 und 5.15. Noch kein Fixpaket genannt.
Fedora 43 / 44	Die Builds 7.2.11-100.fc43 und 7.2.11-200.fc44 basieren auf dem gefixten Upstream, stehen in Bodhi aber noch auf pending. Die zuletzt stabilen 7.2.10-Updates sind kein Nachweis dieses Fixes. Fedora 45 hat mit 7.2.11-300.fc45 ebenfalls einen noch ausstehenden Build.
Arch Linux	linux-lts 6.18.57-1 enthält den Upstream-Fix und ist in Core gelistet. Die abgefragte Paketinformation für linux zeigte noch 7.2.9.arch1-1; dafür ist damit kein Fix belegt. Die beiden Pakete nicht verwechseln.
Alpine Linux 3.24	Die x86_64-Paketliste führt noch linux-lts 6.18.56-r0, also unterhalb des Upstream-Fixes 6.18.57. Kein Fix für dieses Paket belegt; linux-virt, andere Releases und Architekturen separat prüfen. Bei Alpine-Containern zählt der Kernel des Hosts.
Gentoo / selbst gebaute Kernel	Im Gentoo-Paketbaum liegen unter anderem 7.2.11, 6.18.57, 6.12.113, 6.6.159 und 6.1.190. Architektur-Keywords und den tatsächlich gebauten Kernel prüfen. Für eigene Kernel gilt die passende Upstream-Grenze oder der nachgewiesene Backport.

Ein leeres Ergebnis bei dnf updateinfo --cve oder eine noch fehlende CVE-Seite beweist keine Sicherheit. Ebenso wenig hilft es, die letzte Patchtabelle zu Dirty Frag, Januscape oder Zapscape erneut zu verwenden: PwnEscape braucht einen eigenen Fixnachweis.

Proxmox: Warum 7.0.14-24 der richtige Zielstand ist

Das Proxmox-Changelog und die zugehörige Patchübernahme zeigen zwei Schritte:

Proxmox-Kernel	Stand für PwnEscape
7.0.14-22-pve	Vorläufige Patches schützen die Fragmentierung vor Prüfsummen-Metadaten, die in bereits gelesene IP-Header zeigen. Ein früher Schutz, aber noch nicht der später akzeptierte breitere IPv4-Fix.
7.0.14-24-pve	Übernimmt 6785011f8b16 mit den zusätzlichen Prüfungen auch für NFQUEUE, CHECKSUM-Regeln und Software-IPsec-Ausgabe. Das ist der hier empfohlene Mindeststand im 7.0-Zweig.
6.17.13-21-pve	Im geprüften 6.17-Zweig kein entsprechender Backport belegt. Nicht vom Fix im 7.0-Zweig auf diesen Kernel schließen.
6.14.11-9-pve / 6.14-Backport für Bookworm	Kein PwnEscape-Fix nachgewiesen. Die alten Fixes für Copy Fail und Dirty Frag reichen nicht.
6.8.12-43-pve / PVE 8	Im geprüften Bookworm-6.8-Quellzweig kein PwnEscape-Fix belegt. Passenden Herstellerpfad klären; einen PVE-9-Kernel nicht einfach in PVE 8 hineininstallieren.

Damit ist „erst ab 7.0.14-24 gepatcht“ als betrieblicher Zielwert sinnvoll, als vollständige Historie aber zu grob. -22 war bereits teilweise gehärtet. Bei -24 ist der akzeptierte IPv4-Fix im Proxmox-Patchsatz direkt nachweisbar. Ob dein Enterprise-, No-Subscription- oder Test-Repository das Paket anbietet, prüfst du am Node.

Die verfügbaren Paketstände, einen Kernel-Pin und den laufenden Kernel musst du getrennt betrachten. Ein installiertes 7.0.14-24 schützt den Node nicht, solange weiter 7.0.14-21-pve läuft.

Schnelle Prüfung auf dem Host

Die folgenden Befehle sind Diagnosebeispiele für Linux-Hosts, kein Exploit-Test und kein automatischer Sicherheitsnachweis. Zuerst Betriebssystem und Kernel erfassen:

cat /etc/os-release
uname -r
uname -m

Auf Debian, Ubuntu und Proxmox:

dpkg -l 'linux-image*' 'linux-modules*' 'proxmox-kernel*' 'pve-kernel*' 2>/dev/null \
  | awk '/^ii/ {print $2, $3}'

Auf Proxmox zusätzlich:

pveversion -v
apt-cache policy proxmox-kernel-7.0 proxmox-kernel-7.0.14-24-pve-signed
proxmox-boot-tool kernel list
proxmox-boot-tool status

Auf RPM-Systemen beziehungsweise SUSE:

# RHEL, AlmaLinux, Rocky, Oracle, CloudLinux, Fedora, Amazon Linux
rpm -q kernel kernel-core kernel-uek 2>/dev/null

# SUSE / openSUSE
zypper se -si 'kernel*'

Danach den Netzwerkpfad ansehen:

ip -details link show
ip tuntap show
bridge link show
sysctl net.ipv4.ip_forward
sysctl net.bridge.bridge-nf-call-iptables 2>/dev/null

# Proxmox: virtuelle Netzwerkkarten der konfigurierten VMs
grep -HnE '^net[0-9]+:' /etc/pve/qemu-server/*.conf 2>/dev/null

virtio und TAP-Interfaces sind Hinweise auf einen relevanten Einstieg. ip_forward=0 ist umgekehrt keine allgemeine Entwarnung: Der Fix umfasst mehr als klassische IPv4-Router, und zusätzliche Netzwerk-Namespaces können eigene Einstellungen haben. Für eine Bewertung brauchst du auch Firewall-, Bridge-, Overlay- und MTU-Konfiguration.

Patchen und mit fehlenden Updates umgehen

Auf einem Proxmox-9-Node mit dem passenden Repository ist der reguläre Updateweg:

sudo apt update
apt-cache policy proxmox-kernel-7.0 proxmox-kernel-7.0.14-24-pve-signed
sudo apt full-upgrade

Vor der Bestätigung prüfen, ob tatsächlich ein gefixter Kernel installiert wird. Anschließend die Workloads kontrolliert auf bereits gepatchte Nodes verlagern oder herunterfahren und den Host im Wartungsfenster neu starten:

sudo reboot

Nach dem erneuten Verbinden:

uname -r
pveversion -v
proxmox-boot-tool kernel list

Im beschriebenen 7.0-Zweig muss nun mindestens 7.0.14-24-pve laufen. Für andere Distributionen gilt derselbe Ablauf mit deren Paketverwaltung und belegtem Fixpaket. Solange der Tracker nur Pending Fix oder needs-triage meldet, ist „alle verfügbaren Updates installiert“ allein kein Abschlussnachweis.

Wenn noch kein Paket bereitsteht, bleiben betriebliche Maßnahmen: betroffene Nodes aus der Aufnahme neuer fremder Workloads nehmen, bestehende Gäste auf nachweislich abgesicherte Systeme verschieben oder bis zum Fix stoppen. TUN-/TAP-Geräte und zusätzliche Netzwerkrechte nur dort vergeben, wo sie gebraucht werden. Ein bestehender VM-Kunde braucht allerdings keinen direkten Zugriff auf /dev/net/tun des Hosts: Die Weitergabe der Gastdaten übernimmt sein VMM.

Ein pauschales „Offload mit ethtool -K abschalten“ empfehlen wir hier nicht. Laut Kernel-Dokumentation kann der Stack fehlendes Hardware-Offload durch Softwareberechnung ersetzen. Genau in solchen Software-Helfern liegt der Fehler. Eine Änderung auf der physischen NIC oder im Gast belegt deshalb keine wirksame Mitigation; bei einer fremdkontrollierten VM kann der Gast die eigene Konfiguration ohnehin ändern.

Auch eine Firewall vor dem Hypervisor, eine andere MTU oder das Abschalten von Nested KVM ersetzt den Kernel-Fix nicht. Eine engere Zwischenlösung muss der Vendor für den konkreten Netzwerkpfad bestätigen. Bei Livepatching brauchst du den Nachweis, dass CVE-2026-99999 beziehungsweise der entsprechende Backport im laufenden Kernel aktiv ist. Ein KernelCare-, Ksplice- oder Livepatch-Abo allein sagt darüber nichts aus.

Unsere Einschätzung für produktive Umgebungen

Bei einem Hoster mit fremden Root-VMs gehört PwnEscape nach oben auf die Wartungsliste. Der mögliche Schaden endet nicht beim angreifenden Kunden. Ein Host-Absturz trifft alle Gäste auf dem Node; Host-Root kann die gesamte Mandantentrennung aufheben.

Für den Betrieb würde ich pro Node drei Dinge dokumentieren: das zugehörige Fixpaket, den tatsächlich gebooteten Kernel und die Prüfung des virtuellen Netzwerkpfads. Im Cluster ist ein einzelner ungepatchter Zielnode weiter relevant, auch wenn die übrigen Hosts schon aktualisiert sind. Eine Migration dorthin kann Workloads wieder auf eine verwundbare Plattform bringen.

Wer den eigenen Netzwerkaufbau nicht sicher einordnen kann, braucht zuerst eine Bestandsaufnahme. Für einen Proxmox-Cluster gehören dazu auch Boot-Pins, verfügbare Ausweichkapazität und ein funktionierender Rückweg beim Kernelwechsel. Ein technischer Sicherheitscheck sollte diese konkreten Betriebsfragen beantworten.

Update-Log

• 15.10.2026, 22:42 Uhr CEST: Erstveröffentlichung. Linux-CVE-Datensatz und Upstream-Fixstände geprüft; Proxmox-Vorfix 7.0.14-22 vom breiteren Fix 7.0.14-24 abgegrenzt. Debian-, Ubuntu-, AWS-, Fedora-, Arch- und Gentoo-Stände ergänzt. Nicht bestätigte Vendor-Fixes ausdrücklich offen gelassen. Zwei Originalgrafiken von pwn.ai lokal eingebunden.

Quellen

• pwn.ai: PwnEscape, Researcher-Bericht und Originalgrafiken
• Vercel: Findings from the $1 million Vercel Sandbox challenge
• Linux-CNA: CVE-2026-99999 mit Bewertung und Versionsgrenzen
• Upstream-Fix: ipv4: validate checksum_start before completing checksum
• Originalreport: prevent partial checksums from modifying IPv4 headers
• Fragmentierungs-Patch und Hinweis auf TUN ohne VM
• Linux-Dokumentation: Checksum Offloads
• Proxmox: Kernel-7.0-Changelog
• Proxmox: Übernahme des breiteren IPv4-Fixes und Abgrenzung zum Vorfix
• Proxmox: Kernel-6.8-Zweig, 6.14-Zweig und 6.17-Zweig
• Debian Security Tracker: CVE-2026-99999
• Ubuntu: offizieller CVE-Tracker im Quellrepository
• Amazon Linux Security Center: CVE-2026-99999
• Fedora 43: 7.2.11, Fedora 44: 7.2.11 und Fedora 45: 7.2.11
• Arch-Paketdaten: linux und linux-lts
• Gentoo: gentoo-kernel-Paketbaum