Linux-Kernel CVE-2026-99999: Eine nachgereichte Prüfsumme überschreibt den bereits geprüften IPv4-Header

TL;DR — 90 Sekunden

• Was: Der Kernel übernimmt Prüfsummen-Metadaten (csum_start, csum_offset) aus virtio-net, TUN und Packet-Sockets. Vor der nachgereichten Berechnung prüfte er nicht, ob der Startwert hinter dem IPv4-Header liegt, sodass skb_checksum_help() den bereits geprüften Header überschreiben konnte.
• Schwere: Die Kernel-CNA bewertet mit CVSS 9.3 (AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H), Red Hat und Amazon Linux mit 8.8. Seit dem 17. Oktober sind mehrere unverifizierte Repositories zu der CVE erschienen, ein bestätigter Exploit ist nicht bekannt, und im CISA-KEV-Katalog steht die Lücke nicht.
• Wen es trifft: In erster Linie Linux-Hosts, auf denen nicht vertrauenswürdige Gast-VMs über virtio-net laufen, also eigene KVM-, QEMU- oder Firecracker-Hosts, Sandbox-Plattformen und CI-Runner mit MicroVMs. Lokale Wege über TUN und Packet-Sockets sind im Code angelegt, für gewöhnliche Container-Nodes aber nicht nachgewiesen.
• Was zu tun ist: Einen Kernel mit Commit 6785011f8b16 oder dem Backport deiner Distribution einspielen und neu starten. Upstream ist der Fix in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 und 7.2.11 enthalten, außerdem im Linux 7.3 vom 18. Oktober. Für Amazon Linux und Debian gelten eigene Paketversionen.
• Was vorher geschützt hätte: Nicht vertrauenswürdigen Gast-VMs kein Checksum-Offload anbieten, Pods mit dem seccomp-Profil RuntimeDefault betreiben und unprivilegierte User Namespaces dort abschalten, wo sie niemand braucht. Image-Scans und Firewall-Regeln helfen gegen diesen Mechanismus nicht.

Nachgereichte Prüfsummen und ein Header, der zweimal gelesen wird

Prüfsummen kosten Rechenzeit, deshalb überlassen Betriebssysteme ihre Berechnung gern der Netzwerkkarte. Die Kernel-Doku beschreibt, wie das unter Linux abläuft. Der Netzwerkstack markiert ein ausgehendes Paket als CHECKSUM_PARTIAL und hält in zwei Feldern fest, ab welcher Position die Prüfsumme bis zum Paketende gebildet wird (csum_start) und an welcher Stelle das Ergebnis landet (csum_start + csum_offset). Kann das Gerät die Rechnung nicht übernehmen, holt der Kernel sie mit skb_checksum_help() in Software nach. Gerechnet wird also erst spät, während die Entscheidung, wohin das Ergebnis geschrieben wird, schon früh gefallen ist. Dazwischen arbeiten andere Teile des Stacks mit demselben Paket.

In virtualisierten Netzen kommen die beiden Felder vom Gast. Ein virtio-net-Gerät schickt jedem Paket einen kleinen Header voraus, in dem der Gast das Offload anfordert. Ob er das darf, regelt die Fähigkeit VIRTIO_NET_F_CSUM, die im Kernel-Header als „Host handles pkts w/ partial csum“ beschrieben ist. Wie das Paket auf dem Host ankommt, beschreibt der CVE-Eintrag sehr konkret: Der VMM schreibt den Frame des Gasts in ein TAP-Gerät, und tun_get_user() übergibt ihn mitsamt den Metadaten an den IPv4-Stack. Der VM-Pfad und der TUN-Pfad sind damit im Kern derselbe. Daneben nehmen auch Packet-Sockets den virtio-Header an, und genau diese beiden Eingänge nennt der Fix als Ursprung: „tun: Allow GSO using virtio_net_hdr“ und „packet: Add GSO/csum offload support“. Laut CVE-Eintrag reicht die betroffene Spanne bis Linux 2.6.27 zurück.

Genau hier lag der Fehler. Beim Annehmen prüfte der Kernel zwar, ob csum_start zu weit vorn liegt, laut Analyse des Entdeckers aber relativ zur momentanen Sicht auf den Puffer und nicht relativ zum IPv4-Header. Enthält das Paket zusätzliche Link-Layer-Strukturen, besteht ein geschickt gewählter Startwert diese Prüfung und zeigt trotzdem mitten in den IPv4-Header. Der Host liest den Header anschließend ganz regulär, findet im Feld IHL den Wert 5, also 20 Byte, und betrachtet das Paket als geprüft.

Warum das gefährlich wird, zeigt ip_do_fragment() in net/ipv4/ip_output.c. Muss ein Paket für den Weg nach draußen zerlegt werden, rief die Funktion zuerst skb_checksum_help() auf und las erst danach den IPv4-Header und seine Länge. Die nachgereichte Prüfsumme landete dort, wo der Gast es wollte, im Fall des Entdeckers auf dem Byte mit Version und IHL. Aus 5 wurde 15, und der Header galt fortan als 60 Byte lang. Beim Erzeugen der Fragmente kopierte der Kernel deshalb 60 Byte als Header, obwohl im linearen Teil des Puffers nur 28 Byte gültige Daten lagen. Die restlichen 32 Byte stammten aus dem angrenzenden Host-Speicher und verließen den Host als vermeintliche IP-Optionen.

Der Entdecker bringt das Muster auf einen Satz: Verschiedene Teile von Linux durften unterschiedlichen Versionen desselben Pakets vertrauen. Ich halte das für den eigentlichen Kern des Falls. Jede der beiden Prüfungen war für sich genommen vernünftig, nur bezogen sie sich auf verschiedene Zeitpunkte. Zwischen Prüfung und Verwendung lag ein Schreibzugriff, dessen Ziel ein weniger vertrauenswürdiger Absender bestimmt hatte. Das ist das bekannte Time-of-check-to-time-of-use-Problem, nur dass es diesmal zwischen zwei Schichten desselben Kernels auftritt und nicht zwischen zwei Prozessen.

Was der Fix-Commit ändert

Commit 6785011f8b16 von Michael S. Tsirkin trägt den Titel „ipv4: validate checksum_start before completing checksum“. Er wurde am 8. Oktober in net.git und am 14. Oktober in Mainline aufgenommen und ändert sechs Dateien. In include/net/ip.h kommt die Hilfsfunktion ip_check_csum_start() hinzu, die einen Fehler meldet, sobald csum_start vor dem Ende des IPv4-Headers liegt. Als Ende gilt dabei die Position des Netzwerk-Headers plus seine tatsächliche Länge. Diese Prüfung läuft jetzt überall dort vor skb_checksum_help(), wo ein IPv4-Paket mit ausstehender Prüfsumme fertiggestellt wird. Das sind fünf Stellen: ip_do_fragment(), die Fragmentierung im Bridge-Conntrack (nf_br_ip_fragment()), die Prüfsummenhilfe von NFQUEUE, das iptables-Ziel CHECKSUM und xfrm_output() für IPsec. Schlägt sie fehl, verwirft der Kernel das Paket, statt die Prüfsumme zu schreiben.

Aufschlussreich ist, wo der Commit ansetzt. Er sichert die Stellen ab, an denen die Prüfsumme geschrieben wird, und lässt die Prüfung beim Annehmen der Pakete vorerst, wie sie ist. Die Commit-Nachricht sagt das offen: Solche Pakete sollten gar nicht erst hereinkommen, die neue Prüfung sei Defense in Depth, und eine vollständigere Validierung am Eingang brauche noch Arbeit. Laut Entdecker drehte sich das Review um die Frage, ob eine breite Prüfung in einer zentralen Hilfsfunktion oder gezielte Prüfungen an jeder einzelnen dieser Stellen riskanter sind, denn verschachtelte Header, IP-Optionen und IPv6 lassen sich mit einer einfachen festen Grenze schlecht abbilden. Außerdem beschränkt sich der Fix auf IPv4. Für IPv6 sind weder Abfluss noch Rechteausweitung gezeigt, und die weiteren Bedenken der Forscher zu später veränderten Transport-Feldern deckt er ausdrücklich nicht ab. Mit dem Patch schließt du die bewiesene Lücke, die Fehlerklasse dahinter bleibt aber offen.

Vom Gastpaket zum Host-Speicher: Voraussetzungen und Schaden

Der CVE-Eintrag beschreibt als Ausgangslage eine bösartige MicroVM, die präparierte Pakete über ihre virtio-net-Schnittstelle schickt. Mehr braucht es nicht. Der Gast benötigt laut Eintrag weder Zugangsdaten noch Capabilities auf dem Host, und Root im eigenen Gast-Kernel hat jeder, der eine VM mietet oder in einer Sandbox Code ausführen darf. Ab Werk betroffen ist damit jeder ungepatchte Linux-Host, der Gästen ein virtio-net-Gerät mit Checksum-Offload anbietet und ihre Pakete durch den eigenen IP-Stack schickt, typischerweise über ein TAP-Gerät mit Bridge oder NAT. QEMU schaltet die unterstützten Offloads laut libvirt-Doku standardmäßig ein, Firecracker bietet VIRTIO_NET_F_CSUM laut Quelltext immer an. Ob ein konkreter Host durch die betroffenen Funktionen läuft, hängt nach Aussage des Entdeckers an Netzwerkimplementierung, Kernel-Version und Konfiguration. Hosts, die Gastpakete per vhost-user, DPDK oder SR-IOV am Kernel-Stack vorbeiführen, liegen nach meiner Lesart außerhalb des Kernbereichs.

Die Angriffskette ist konzeptionell kurz. Der Gast schickt ein Paket, dessen Offload-Metadaten auf den IPv4-Header zeigen, und sorgt dafür, dass der Host es fragmentieren muss. Der Host prüft den Header, schreibt danach die Prüfsumme hinein und kopiert beim Fragmentieren 32 Byte seines eigenen Speichers in das ausgehende Paket. Bei Vercel landeten diese Bytes in Paketen, die der Gast ins Internet schickte, und zwar so lange, wie er weitersendete. Zwei Pakete genügten laut Vercel, um einen Host zum Absturz zu bringen und damit jede Sandbox auf ihm zu beenden. Auf eigenen KVM- und Firecracker-Systemen in Vercels Konfiguration kam der Entdecker außerdem zu gezielten 64-Byte-Schreibzugriffen in den Host-Kernel und zu Befehlen mit Root-Rechten auf dem Host. Die Einzelheiten dieser Schreibkette hält er für einen zweiten Teil zurück.

Am schwersten wiegt das dort, wo sich viele Mandanten einen Host teilen. Ein Absturz trifft alle VMs auf diesem Kernel, im abgeflossenen Speicher können Schlüssel oder Tokens anderer Gäste stecken, und mit Root auf dem Host ist jede Mandantentrennung hinfällig. Vercel betont, dass während der Challenge weder Kundendateien noch Secrets oder Anwendungsdaten abgeflossen sind.

Genauso wichtig ist, wer nur glaubt, betroffen zu sein. Für EC2, Lambda und Fargate stellt das AWS-Bulletin 2026-137-AWS klar, dass die von AWS betriebene Infrastruktur nicht betroffen ist und dort nichts zu tun bleibt. Das betrifft allerdings nur die Ebene unter deiner Instanz. Der Kernel in der Instanz selbst enthält die Lücke ebenfalls, und sobald du darauf eigene VMs betreibst, ist sie ein betroffener Host wie jeder andere. Bei Kubernetes-Nodes ohne VMs ist die Lage weniger eindeutig. CloudLinux hält lokale Wege über TUN in einem unprivilegierten User Namespace und über Packet-Sockets nach Lage des Codes für plausibel, konnte in eigenen Tests aber weder einen Kernel-Oops noch einen KASAN-Befund auslösen. Ich stufe Container-Nodes deshalb als möglicherweise betroffen ein, mit deutlich geringerer Dringlichkeit als Hosts mit nicht vertrauenswürdigen Gast-VMs. Ob ein Container auf einem gewöhnlichen Node den Fragmentierungspfad des Hosts tatsächlich erreicht, ist öffentlich nicht belegt.

Keine der Primärquellen nennt einen öffentlichen Proof of Concept, und CloudLinux schrieb ausdrücklich, dass es keinen gibt. Seit dem 17. Oktober sind auf GitHub allerdings acht Repositories von sechs Autoren zu dieser CVE erschienen. Die beiden, die ich mir angesehen habe, sind ein Scanner und ein unverifizierter Proof of Concept, der laut eigener Beschreibung den Speicherabfluss und das Aushebeln von KASLR nachstellt, nicht aber die Rechteausweitung. Einen bestätigten Exploit bis Root gibt es damit weiterhin nicht, die Aufmerksamkeit für den Mechanismus ist aber groß. Der Entdecker hat den zweiten Teil seiner Analyse bisher nicht veröffentlicht. Im CISA-KEV-Katalog steht die Lücke nicht, und CISA bewertet in der SSVC-Einschätzung des CVE-Eintrags die Ausnutzung mit „none“. EPSS schätzt die Wahrscheinlichkeit einer Ausnutzung in den nächsten 30 Tagen auf 0,21 Prozent. Für Betreiber von Sandbox-Plattformen halte ich diese Zahl für zu niedrig gegriffen, denn der Mechanismus ist öffentlich beschrieben, der Fix zeigt die betroffenen Stellen, und der zweite Teil mit der Schreibkette ist angekündigt.

Kernel-Fix, Backports und der Neustart, der dazugehört

Vollständig schützt gegen die bewiesene Lücke nur ein Kernel mit dem Fix, und auch der erst, wenn der Host in diesen Kernel neu gestartet ist. Upstream steckt Commit 6785011f8b16 in den Stable-Versionen 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 und 7.2.11, und das am 18. Oktober erschienene Linux 7.3 enthält ihn ebenfalls. Distributionen portieren den Fix in ihre eigenen Kernel zurück, und deren Versionsnummern liegen oft unter der Upstream-Version mit dem Fix. Wer nur mit der Upstream-Liste vergleicht, zieht deshalb leicht falsche Schlüsse. Maßgeblich ist das Advisory deiner Distribution.

Für Amazon Linux nennt das AWS-Bulletin die ersten Kernel mit Fix. Unter Amazon Linux 2 sind das 4.14.355-287.750.amzn2, 5.4.302-229.494.amzn2, 5.10.269-270.1108.amzn2 und 5.15.220-156.256.amzn2. Unter Amazon Linux 2023 sind es kernel 6.1.188-233.385.amzn2023, kernel6.12 6.12.110-135.201.amzn2023 und kernel6.18 6.18.51-120.162.amzn2023. Das Amazon Linux Security Center führt alle Pakete als Fixed, für Amazon Linux 2 unter ALAS2-2026-3962, ALAS2KERNEL-5.4-2026-131, ALAS2KERNEL-5.10-2026-133 und ALAS2KERNEL-5.15-2026-117, für Amazon Linux 2023 unter ALAS2023-2026-3197, ALAS2023-2026-3196 und ALAS2023-2026-3192. AWS rät Betreibern eigener virtio-net- und KVM-Hosts, die Pakete einzuspielen und neu zu starten, und nennt ausdrücklich keinen Workaround.

Debian hat den Fix für Bookworm mit linux 6.1.190-1 (DLA-4841-1) und für Trixie mit 6.12.113-1 (DSA-6568-1) ausgeliefert. Red Hat stuft die Lücke als Important ein, führt alle betreuten Produktstränge als betroffen und arbeitet laut CVE-Seite noch an Fixes. Wolfi berührt der Fall nicht direkt, weil Container-Images keinen eigenen Kernel mitbringen und immer den des Hosts nutzen.

Der Fix ändert keine Konfiguration und wirkt nur auf Pakete, deren Metadaten in den IPv4-Header zeigen. Diese verwirft der Kernel jetzt, und im regulären Betrieb sollten sie nicht vorkommen. Die eigentliche Stolperfalle ist organisatorischer Natur. Ein installiertes, aber nicht gebootetes Kernel-Paket schützt nicht, und auf Hosts mit vielen Gästen ist der Neustart der teure Teil. Auf Virtualisierungs-Hosts verschiebst du deshalb zuerst die Gäste auf gepatchte Maschinen oder fährst sie geplant herunter, startest neu und prüfst danach den laufenden Kernel. Kubernetes-Nodes tauschst du am saubersten aus, statt sie im Betrieb zu aktualisieren, etwa mit einem neuen AMI für die Node Group, das die Nodes nacheinander ersetzt. Livepatches wie KernelCare rollen laut CloudLinux gerade aus. Den Neustart ersparen sie dir aber nur, wenn dein Anbieter den Patch für deinen Kernel tatsächlich liefert.

Härtung über den Patch hinaus: Offload, Capabilities und Namespaces

Bevor es um einzelne Maßnahmen geht, lohnt die Frage, was gegen diesen Mechanismus überhaupt wirken kann. Der Fehler steckt im Host-Kernel und wird von Werten ausgelöst, die ein weniger vertrauenswürdiger Absender in einen Paketpuffer schreibt. Daran ändern weder ein Container-Image noch eine Firewall-Regel oder eine gehärtete Anwendung im Gast etwas. Wirksam ist, was einen der Eingänge schließt, über die solche Metadaten hereinkommen: das Offload von virtio-net, TUN und Packet-Sockets mit virtio-Header. Dazu kommt alles, was den Schaden begrenzt, falls jemand den Host-Kernel trotzdem erreicht. CloudLinux weist zu Recht darauf hin, dass jede dieser Maßnahmen nur eine Voraussetzung wegnimmt und keine den Kernel-Fix ersetzt.

Kein Checksum-Offload für nicht vertrauenswürdige Gast-VMs

Der Gast kann csum_start nur deshalb vorgeben, weil der Host ihm Checksum-Offload anbietet. Fehlt VIRTIO_NET_F_CSUM, muss der Gast vollständige Prüfsummen schicken, und dem bewiesenen Angriff fehlt die Grundlage. Unter libvirt mit QEMU steuerst du die Offloads des Hosts über das Element <host> im <driver>-Block der Netzwerkschnittstelle. Das Beispiel der libvirt-Doku setzt dort csum zusammen mit den Segmentierungs-Offloads gso, tso4, tso6, ecn und ufo auf off. CloudLinux nennt diese Maßnahme als Teilschutz und zählt ihre Grenzen gleich mit auf. Sie wird pro VM gesetzt, braucht einen Neustart des Gasts, kostet Durchsatz und ist gegen genau diese Lücke noch nicht getestet. Bei Firecracker gibt es den Hebel nicht. Laut Quelltext setzt das virtio-net-Gerät VIRTIO_NET_F_CSUM fest, eine Einstellung zum Abschalten sehe ich dort nicht. Firecracker-Hosts bleibt deshalb nur der Kernel-Fix. Wo du QEMU einsetzt, ist das abgeschaltete Offload dagegen die Maßnahme, die am direktesten am Mechanismus ansetzt, bis jeder Host gepatcht ist.

seccomp-Profil RuntimeDefault und Pod Security „restricted“

Auf Container-Nodes führt der lokale Weg, den CloudLinux beschreibt, über einen eigenen User Namespace. Wer einen anlegt, erhält darin laut user_namespaces(7) den vollen Satz an Capabilities, und mit einem eigenen Netzwerk-Namespace dazu darf der Prozess dort Netzwerkgeräte wie TUN anlegen, unabhängig davon, was der Container von außen mitbekommen hat. An dieser Stelle greift das Standardprofil von containerd. In den aktuellen Releases 1.7 und 2.1 erlaubt es unshare und setns nur Containern mit CAP_SYS_ADMIN, und clone lässt es ohne diese Capability nur zu, wenn keines der Flags für neue Namespaces gesetzt ist, CLONE_NEWUSER eingeschlossen. Ein gewöhnlicher Container kommt damit weder an einen eigenen User Namespace noch an einen eigenen Netzwerk-Namespace. Das leite ich aus dem Quelltext des Profils ab, getestet haben es die Entdecker nicht.

Kubernetes setzt das Profil allerdings nicht von selbst. Ohne Angabe läuft ein Container laut Kubernetes-Doku als Unconfined, solange das Kubelet nicht mit --seccomp-default beziehungsweise seccompDefault: true in der Kubelet-Konfiguration läuft. Setze deshalb seccompProfile.type: RuntimeDefault im Pod oder schalte die Vorgabe im Kubelet ein. Am einfachsten erzwingst du das mit dem eingebauten Pod Security Admission. Das Label pod-security.kubernetes.io/enforce: restricted auf einem Namespace weist jeden Pod ab, der kein seccomp-Profil setzt oder nicht capabilities.drop: ["ALL"] verlangt. Damit bekommt ein Pod auch kein CAP_NET_ADMIN, das laut Kernel-Doku zum Anlegen von Netzwerkgeräten nötig ist. Ausnahmen brauchen meist nur CNI- und Storage-Komponenten in Systemnamespaces, und die hältst du bewusst fest.

Unprivilegierte User Namespaces auf Hosts mit nicht vertrauenswürdigem Code

Auf Hosts, auf denen Menschen oder Pipelines Code direkt und ohne Container ausführen, etwa auf CI-Runnern mit Shell-Executor oder auf Build-Servern, gibt es diese seccomp-Schranke nicht. Dort führt der lokale Weg ungehindert über den User Namespace. Wie viele davon ein Nutzer anlegen darf, regelt /proc/sys/user/max_user_namespaces, und CloudLinux nennt user.max_user_namespaces=0 als Teilmaßnahme. Der Preis ist hoch. Laut namespaces(7) gilt die Grenze für alle Nutzer einschließlich UID 0, deshalb brechen damit rootless Container, die Sandboxen von Chrome und Flatpak und auch Kubernetes-Pods mit hostUsers: false. Gegen den VM-Pfad hilft der Schalter nicht. Sinnvoll ist er auf dedizierten Runner- und Build-Hosts, bei denen du sicher weißt, dass nichts davon läuft.

Sandbox-Hosts so planen, als ob der Kernel fällt

Wer nicht vertrauenswürdigen Code in VMs ausführt, sollte davon ausgehen, dass dies nicht die letzte Lücke ihrer Art war. Vercel zieht genau diesen Schluss aus der Challenge und nennt strengere Schutzmaßnahmen je Sandbox, aktuelle Host-Kernel, abgeschaltete Nested Virtualization und den Jailer von Firecracker, der jeden MicroVM-Prozess einschränkt. Den Jailer halte ich für richtig, er begrenzt aber den VMM-Prozess und nicht den Host-Kernel und wirkt gegen diesen Fehler deshalb nicht direkt. Mehr bringt eine klare Trennung. Auf Hosts mit nicht vertrauenswürdigem Code liegen dann keine Secrets anderer Systeme, keine Cluster-Zugangsdaten und keine sensiblen Workloads, sodass ein Speicherabfluss dort wenig findet. Egress-Regeln für Sandboxen erschweren zusätzlich den Abtransport abgeflossener Bytes, verhindern ihn aber nicht sicher, solange der Gast überhaupt nach außen senden darf.

Was hier nicht hilft

Image-Scanner und minimale Base-Images wie Wolfi oder distroless laufen bei dieser Lücke ins Leere, weil der verwundbare Code im Host-Kernel liegt und in keinem Image vorkommt. Ein CVE-Gate in der Image-Pipeline schlägt deshalb nicht an. Host-Scanner erkennen die Lücke nur dann zuverlässig, wenn sie die Backports der Distribution kennen und den laufenden Kernel prüfen statt des installierten Pakets.

NetworkPolicies und Firewall-Regeln filtern nach Adressen und Ports, der Fehler steckt aber in der Verarbeitung eines Pakets, das der Host ohnehin annimmt. Eine Regel, die ihn abfängt, kennt keine der geprüften Analysen. Auch abgeschaltete Offloads auf der physischen Netzwerkkarte des Hosts sind keine belegte Abhilfe, denn die Metadaten stammen vom Gast und nicht von der Karte. Härtung im Gast bringt beim VM-Pfad ebenfalls nichts, weil der Angreifer dort ohnehin Root ist, und readOnlyRootFilesystem spielt keine Rolle, weil der Angriff keine Dateien schreibt.

Mehr zu Pod Security, seccomp-Profilen und der Trennung von Workloads findest du in der Serie TYPO3 auf Kubernetes unter IT-Grundschutz.

Erkennung und Prüfung

Ob ein Host betroffen ist, entscheidet der laufende Kernel, den uname -r anzeigt, und nicht das zuletzt installierte Paket. Vergleiche ihn mit dem Advisory deiner Distribution, bei Amazon Linux mit den Versionen aus dem AWS-Bulletin. Danach geht es um die Frage, wie exponiert der Host ist. Laufen dort VMs mit virtio-net, deren Inhalt du nicht kontrollierst, hat er höchste Priorität. Auf Kubernetes-Nodes zählt, welche Pods noch zusätzliche Capabilities wie NET_ADMIN tragen, privilegiert laufen oder ohne seccomp-Profil starten. Namespaces ohne das Label für „restricted“ sind der schnellste Einstieg in diese Liste.

Schwieriger ist die Frage, ob die Lücke schon ausgenutzt wurde. Weder die Kernel-Entwickler noch AWS, Vercel oder der Entdecker nennen IoCs. Aus dem Mechanismus ergeben sich zwei Hinweise, die ich selbst ableite und die keine Herstellervorgabe sind. Zum einen hat der Entdecker Host-Abstürze mit wenigen Paketen gezeigt, ungeklärte Kernel-Oopses oder Neustarts auf Hosts mit nicht vertrauenswürdigen Gast-VMs verdienen also einen zweiten Blick. Zum anderen tragen die Fragmente beim Speicherabfluss einen IPv4-Header mit 60 Byte und vermeintlichen Optionen. IP-Optionen sind im normalen Verkehr selten, und ein Mitschnitt des ausgehenden Gastverkehrs, der nach Fragmenten mit IHL 15 sucht, kann Auffälligkeiten zeigen. Ein unauffälliges Ergebnis beweist allerdings wenig, denn der Abfluss verläuft leise.

Bei einem Verdacht behandelst du den Speicher des Hosts als offengelegt. Verschiebe die Gäste auf gepatchte Hosts, starte den Host mit dem neuen Kernel neu und rotiere alles, was in seinem Speicher lag, also seine eigenen Zugangsdaten, Schlüssel anderer Gäste und Tokens von Agenten oder Kubelets. Besteht der Verdacht auf Root-Rechte, setzt du den Host neu auf, statt ihn zu reparieren.

Betreiberempfehlung

Akut handeln solltest du, wenn auf deinen Linux-Hosts VMs laufen, deren Inhalt du nicht kontrollierst. Das betrifft Sandbox-Plattformen für Code oder KI-Agenten genauso wie CI-Runner mit Firecracker- oder QEMU-Gästen, KubeVirt oder Kata Containers mit nicht vertrauenswürdigen Workloads und vermietete VMs auf eigener Hardware. Spiel dann den Kernel deiner Distribution mit dem Fix ein, starte neu und prüfe den laufenden Kernel. Bis es so weit ist, nimmst du nicht vertrauenswürdigen Gast-VMs unter QEMU das Checksum-Offload und hältst sensible Workloads von diesen Hosts fern.

Beobachten genügt, wenn auf deinen Hosts keine Gast-VMs mit Code von Dritten laufen, etwa bei EKS-Nodes oder k3s-Servern mit eigenen Workloads, deren Pods mit RuntimeDefault und nach „restricted“ laufen. Dann gehört das Kernel-Update ins nächste reguläre Wartungsfenster. Bis dahin lohnt der Blick, welche Pods noch ohne seccomp-Profil laufen, denn das zu ändern hilft weit über diese Lücke hinaus.

Unabhängig vom Einzelfall gilt, was ich bei jeder Lücke sage: Patches und Updates gehören automatisiert, und bei Kernel-Lücken gilt das für Nodes genauso wie für Pakete. Wenn Renovate oder Dependabot neue AMI-IDs, Betriebssystem-Versionen und Helm-Charts selbstständig als Merge Request vorschlagen und die Pipeline den Node-Austausch zuerst in einem Staging-Cluster durchspielt, ist ein Kernel-Fix wie dieser eine Sache von Stunden statt Wochen. Eine Karenzzeit für Routine-Updates schützt dabei vor kompromittierten Releases, Sicherheitsupdates nimmst du davon aus. Bringt ein neuer Kernel doch einen Bruch mit, etwa weil eine ungewöhnliche Netzwerk-Konfiguration plötzlich Pakete verliert, fällt das im Test auf und nicht in Produktion. Wer Hosts dagegen von Hand aktualisiert, hat in der Urlaubszeit schnell Wochen ohne Patch und danach einen großen Sammel-Neustart, bei dem vieles gleichzeitig schiefgehen kann.

Fazit

PwnEscape ist weder ein Fehler in KVM noch einer in Firecracker. Es ist ein Fehler in der Frage, wie lange eine Prüfung gilt. Der Host prüfte den IPv4-Header, ließ danach einen Schreibzugriff zu, dessen Ziel der Gast bestimmt hatte, und verließ sich anschließend wieder auf den geprüften Wert. Die Lehre daraus reicht weit über den Netzwerkstack hinaus. Metadaten, die eine weniger vertrauenswürdige Seite mitliefert, sind Eingaben wie alle anderen, auch wenn sie scheinbar nur festlegen, wo später gerechnet wird. Und eine Validierung ist nur so viel wert wie die Zeitspanne zwischen Prüfung und Verwendung, in der niemand mehr schreiben darf. Wie lange solche Annahmen im Kernel überleben können, hat im Sommer schon GhostLock gezeigt. Für den Betrieb folgt daraus zweierlei: Kernel-Updates schnell und automatisiert ausrollen und jedem Workload nur die Wege in den Kernel lassen, die er wirklich braucht.

Quellen

• pwn.ai: PwnEscape, Guest-to-Host KVM Escape (CVE-2026-99999)
• Linux Fix-Commit 6785011f8b16: ipv4: validate checksum_start before completing checksum
• CVE-Eintrag CVE-2026-99999 (Kernel-CNA, inkl. CVSS-Begründung)
• NVD: CVE-2026-99999
• FIRST: EPSS
• Vercel: Findings from the 1 million dollar Vercel Sandbox Challenge
• AWS Security Bulletin 2026-137-AWS
• Amazon Linux Security Center: CVE-2026-99999
• Debian Security Tracker: CVE-2026-99999
• Red Hat: CVE-2026-99999
• CloudLinux: CVE-2026-99999 guest-to-host escape
• Kernel-Doku: Checksum Offloads
• Kernel-Doku: TUN/TAP
• libvirt: Domain XML format, NIC driver-specific options
• Firecracker: virtio-net-Gerät (Feature-Bits)
• man7: user_namespaces(7)
• man7: namespaces(7)
• containerd 2.1.4: seccomp-Standardprofil
• Kubernetes Docs: Pod Security Standards
• Kubernetes Docs: seccomp