Security 07.08.2026, 02:42 Aktualisiert: 07.08.2026, 02:42

Zapscape CVE-2026-64561: Root aus der VM, Root auf dem KVM-Host

Zapscape ermöglicht Host-root aus einer VM mit Nested KVM. Patchstände, Proxmox-Fixes, Prüfungen, Mitigation und Exploit-Voraussetzungen.

Von Moritz Mantel · Veröffentlicht: 07.08.2026, 02:42 · Aktualisiert: 07.08.2026, 02:42

Stand: 07.08.2026, 02:42 Uhr CEST. Für die Standardkernel von Proxmox VE 8 und 9 sind Fixes verfügbar. Ubuntu, RHEL und mehrere weitere Vendor-Zweige sind noch offen. Entscheidend ist der laufende Host-Kernel, nicht das installierte Metapaket.

Kurzfassung

CVE-2026-64561, Zapscape: ein Use-after-free in der x86-Shadow-MMU von KVM. Die Lücke sitzt im Host-Kernel und kann bei Nested Virtualization die Grenze zwischen Gast und Host aufheben.
Auswirkung: Der veröffentlichte Exploit erreicht kontrollierte Codeausführung als Root auf dem Host. Die Demo erzeugt dort die Datei /Zapscape mit UID 0.
Voraussetzungen: Root im Gast, ein verwundbarer x86-KVM-Host und Nested Virtualization. Der öffentliche PoC läuft auf AMD SVM/NPT. Intel ist nur unter zusätzlichen EPT-Voraussetzungen angreifbar.
Hoster-Risiko: Root im Gast ist bei VPS- und Cloud-Angeboten normal. Darf der Kunde Nested KVM nutzen, hat er die nötigen Rechte und CPU-Funktionen bereits in seiner VM.
Nicht verwechseln: QEMU ist nicht die verwundbare Komponente. Ein QEMU- oder Gast-Kernel-Update repariert den KVM-Code im Host nicht.
Sofortmaßnahme: Host-Kernel patchen und neu starten. Fehlt ein belegter Fix, sollte Nested Virtualization für nicht vertrauenswürdige VMs deaktiviert werden.
Proxmox: PVE 8 ist mit laufendem 6.8.12-40-pve, PVE 9 mit 7.0.14-9-pve abgedeckt. Gepinnte 6.14- und 6.17-Kernel haben bislang keinen dokumentierten Zapscape-Fix.

Zapscape-Demo: Der PoC erzeugt als Root die Datei /Zapscape auf dem KVM-Host

Demo und Exploit: Hyunwoo Kim / V4bel. Das GIF zeigt die kontrollierte TCG-Testumgebung des Researchers, keinen unverändert einsetzbaren Cloud-Exploit.

Die KVM-Escape-Trilogie

Zapscape gehört zu einer kleinen Serie öffentlich dokumentierter KVM-Escapes. Januscape trifft ebenfalls die x86-Shadow-MMU bei Nested Virtualization, hat aber eine andere Ursache. ITScape greift dagegen KVM auf ARM64 über die virtuelle GICv3-ITS-Emulation an und braucht kein Nested KVM.

Es sind keine Varianten derselben CVE. Die Bugs und Voraussetzungen unterscheiden sich, die angegriffene Grenze ist dieselbe: Gast gegen Host-Kernel.

Was ist Zapscape?

Zapscape ist ein Use-after-free in der klassischen Shadow-MMU von KVM/x86. Diese Schicht verwaltet Schattenkopien von Seitentabellen, wenn ein Gast selbst wieder virtuelle Maschinen startet. KVM muss dann die Speicherübersetzung des echten Hosts, des Gast-Hypervisors und seiner verschachtelten VM zusammenführen.

Der verwundbare Code ist seit Linux 5.9 vorhanden. Das bedeutet nicht, dass jede Distribution mit einer scheinbar älteren Kernelnummer automatisch sicher ist: RHEL, Proxmox und andere Anbieter übernehmen KVM-Code regelmäßig per Backport. Umgekehrt belegt eine hohe Versionsnummer ohne Changelog noch keinen Fix.

Der Mainline-Patch 2abd5287f083 ändert nur wenige Zeilen. Die Ursache ist eine verletzte Lebensdauer-Invariante in einer komplizierten Speicherverwaltung.

Wie die Lücke funktioniert

KVM begrenzt die Zahl seiner Shadow Pages. Wird das Kontingent knapp, räumt make_mmu_pages_available() alte Seiten ab. Dieses Entfernen heißt im KVM-Code „zap“.

Vor dem Fix prüfte KVM zuerst, ob der aktuelle Shadow Root noch gültig ist. Danach konnte der Quota-Reclaim genau diesen Root invalidieren. Die laufende Page-Fault-Behandlung arbeitete trotzdem weiter und legte unter dem inzwischen ungültigen Root neue Shadow Pages an.

Damit bricht eine interne Regel: Ungültige Shadow Pages dürfen nicht in der Liste aktiver MMU-Seiten landen. Genau das passiert hier, weil ein neu erzeugtes Kind den bereits ungültigen Status seines Eltern-Roots erbt.

Der Exploit lässt KVM dieselbe Shadow Page X zuerst als Kind einer verschachtelten Seitentabelle und zugleich als gepinnten Root einer anderen verwenden. Der normale Quota-Reclaim überspringt X wegen dieser Root-Referenz. Über den Parent erreicht der rekursive Pfad die Seite trotzdem, nimmt sie aus der aktiven Liste und markiert sie als ungültig. Freigegeben wird X noch nicht, weil sie weiterhin als Root gepinnt ist.

Die Page-Fault-Behandlung hat ihre Gültigkeitsprüfung zu diesem Zeitpunkt schon hinter sich. Sie arbeitet unter dem jetzt ungültigen X weiter und erzeugt dort das ebenfalls ungültige Kind C. KVM hängt C trotzdem an die Liste aktiver MMU-Seiten. Bei einer späteren Bereinigung landet derselbe Listen-Link zusätzlich auf der Invalid-Liste. C wird freigegeben, sein ehemaliger Nachbar in der aktiven Liste zeigt aber weiter auf diesen Speicher.

Über zwei Cross-Cache-Schritte mit guest_memfd belegt der PoC den freigewordenen Speicher neu. Danach werden Listenoperationen auf dem verwaisten Link zu kontrollierbaren Pointer-Schreibzugriffen. Der Exploit leakt den KASLR-Slide, baut wiederholbare Schreibprimitive auf und lenkt schließlich einen Kernel-Workqueue-Pfad auf einen Usermode Helper um. Der Host führt den vorbereiteten Befehl als Root aus.

Der Patch verschiebt die Gültigkeitsprüfung hinter den Quota-Reclaim. Hat der Reclaim den Root invalidiert, bricht KVM den Fault ab und startet ihn sauber neu, statt unter einem toten Root weiterzuarbeiten.

Wann ein Host praktisch angreifbar ist

Voraussetzung	Einschätzung
x86-KVM-Host mit verwundbarem Kernel	Erforderlich. Zapscape sitzt in `arch/x86/kvm/mmu/`.
Nested Virtualization für den Gast	Erforderlich für den Guest-to-Host-Pfad. Ohne sichtbares `vmx` oder `svm` kann der Gast die nötige verschachtelte Seitentabelle nicht bauen.
Root beziehungsweise Kernelcode im Gast	Für den veröffentlichten Angriff nötig. Bei gemieteten VMs ist Gast-root normalerweise vorgesehen.
AMD SVM/NPT	Der öffentliche PoC nutzt AMD. Dort gibt es keine zusätzliche Intel-PWL5-Bedingung.
Intel VMX/EPT	Betroffen, wenn L1 sowohl vier- als auch fünfstufige EPT Page Walks sieht und die passende Root-/Child-Überlagerung aufbaut. Nur LA57 im normalen Gast reicht nicht als Aussage.
QEMU-Version	Nicht der Fixpunkt. Der Fehler steckt in KVM.
Nur Container ohne KVM-Zugriff	Kein Zapscape-VM-Escape. Ein lokaler Pfad kann aber relevant werden, wenn Prozesse `/dev/kvm` öffnen dürfen.
`/dev/kvm` für unprivilegierte Hostnutzer zugänglich	Zusätzlicher LPE-Pfad. Lokal ist der Aufbau leichter, weil der Angreifer die VMM-IOCTLs direkt kontrolliert.

CONFIG_DEBUG_LIST oder CONFIG_LIST_HARDENED stoppen den aktuellen PoC an seinem Schreibzugriff auf die beschädigte Liste und führen stattdessen zum Crash. Das erschwert diese konkrete Kette, beseitigt den Use-after-free aber nicht. Härtungsoptionen sind hier kein Ersatz für den Patch.

Wie realistisch ist der öffentliche Exploit?

Der Code ist öffentlich und demonstriert eine vollständige Root-Kette. Trotzdem ist er kein fertiger Payload, den jemand unverändert in eine beliebige Cloud-VM kopiert.

Die veröffentlichte Demo startet einen eigens gebauten VMM in einer kontrollierten QEMU-TCG-Umgebung. Für einen Angriff aus einer normalen Kunden-VM müssten die L1-Aktionen in Gast-Kernelcode verlagert und Speicherlayout, Kerneladressen, Konfiguration und Reclaim-Strategie an das Ziel angepasst werden. Auf Intel kommen die beschriebenen EPT-Fähigkeiten hinzu.

Der Portierungsaufwand bremst Gelegenheitstäter. Die Schwachstelle liefert trotzdem starke Primitive, und der Researcher hat die Kette bis zur Root-Ausführung auf dem Host offengelegt. Für einen Hoster mit nicht vertrauenswürdigen Nested-KVM-Gästen ist „der PoC braucht Portierungsarbeit“ kein guter Grund, den Reboot aufzuschieben.

In den geprüften Vendor-, Researcher- und KEV-Quellen fanden wir zum genannten Stand keine Hinweise auf aktive Ausnutzung.

Patchstände nach Distribution und Plattform

Die Tabelle ist eine Momentaufnahme. Prüfe immer das konkrete Vendor-Paket und danach den tatsächlich laufenden Kernel.

Plattform	Stand am 07.08.2026, 02:42 Uhr CEST
Upstream Linux stable	Gefixt in `6.6.148`, `6.12.101`, `6.18.42` und `7.1.6`; Mainline ab `7.2-rc5`. Für die noch gepflegten Stable-Zweige 5.10, 5.15 und 6.1 nennt der Linux-CVE-Datensatz noch keinen Fixstand. Vendor-Kernel auf anderen Zweigen können eigene Backports enthalten.
Debian	Trixie ist über `trixie-security` ab `linux 6.12.101-1` gefixt, Sid ab `7.1.6-1`. Bullseye 5.10, Bookworm 6.1, Trixie ohne Security-Update und Forky 7.1.3 stehen im Tracker als verwundbar.
Ubuntu	Canonical priorisiert die CVE derzeit als `Medium`. Die Standardkernel für 22.04, 24.04 und 26.04 sowie zahlreiche HWE-, Cloud- und ESM-Flavours stehen auf `needed`. Ubuntu 20.04 mit 5.4 und ältere Basiskernel sind nicht betroffen. Ein veröffentlichter Mindest-Fixstand fehlt noch.
Red Hat Enterprise Linux	RHEL 8, 9 und 10 sowie die geprüften RT-Kernel sind als `Affected` markiert; Red Hat nennt noch kein Update. RHEL 6 und 7 sind nicht betroffen. Red Hats vorläufige Bewertung lautet `Important`, CVSS 7,0 mit hoher Angriffskomplexität.
AlmaLinux und Rocky Linux	Zum Stichtag gibt es kein produktspezifisches Erratum mit belegtem Fixpaket. Wegen der RHEL-Kernelbasis sollte ein System nicht allein anhand der Versionsnummer als sicher gelten.
Oracle Linux	Oracle hat UEK-Fixes veröffentlicht: UEK R8 für OL9/10 mit `kernel-uek-6.12.0-204.92.4.4.3` aus `ELSA-2026-500135`, UEK R7 für OL8/9 mit `kernel-uek-5.15.0-322.203.3.4.5` aus `ELSA-2026-500137`. Für RHCK 8/9/10 ist noch kein Oracle-Fix belegt.
Amazon Linux	AL2 Core und AL2 Kernel 5.4 sind nicht betroffen. Die AL2-Extras 5.10/5.15 sowie AL2023 `kernel`, `kernel6.12` und `kernel6.18` stehen auf `Pending Fix`.
Fedora	Fedora 43 ist ab `kernel-7.1.6-101.fc43`, Fedora 44 ab `kernel-7.1.6-201.fc44` gefixt. Nach der Installation muss der neue Kernel laufen.
Arch Linux	Der normale Kernel ist ab `7.1.6.arch1-1` gefixt, `linux-lts` ab `6.18.42-1`.
SUSE und openSUSE	SLES 15 SP7 hat mit `6.4.0-150700.53.76.1` einen Fix in QA, der Status lautet noch `In progress`. SLES 16.0/16.1 und Leap 16.0 führt SUSE für `kernel-default` als nicht betroffen. Leap 15.6 bleibt ohne Fix. Tumbleweed lag beim Recheck auf `7.1.5-1.1` und damit unter dem Upstream-Fix `7.1.6`.
Proxmox VE 8	`proxmox-kernel-6.8 6.8.12-40` enthält den Zapscape-Fix. Nach dem Reboot muss `uname -r` exakt `6.8.12-40-pve` zeigen. Für den optionalen 6.14-Zweig `6.14.11-9-bpo12-pve` ist kein Fix belegt.
Proxmox VE 9	`proxmox-kernel-7.0 7.0.14-9` enthält den Fix; laufend also `7.0.14-9-pve`. Für die alternativen Zweige `6.17.13-21-pve` und `6.14.11-9-pve` ist in den aktuellen Changelogs kein Zapscape-Backport dokumentiert.

Proxmox ist gepatcht, aber nicht automatisch sicher

Die schnelle Vermutung „Proxmox hat noch keinen Patch“ stimmt für die Standardzweige nicht. Proxmox hat CVE-2026-64561 in die aktuellen PVE-8- und PVE-9-Kernel übernommen. Die Pakete sind in den Changelogs von pve-no-subscription und pve-enterprise dokumentiert.

Das praktische Problem sitzt an anderer Stelle: Ein Cluster ist erst geschützt, wenn jeder relevante Node das passende Paket installiert hat und tatsächlich in diesen Kernel gebootet wurde. Ein Node mit installiertem 6.8.12-40, aber laufendem 6.8.12-39-pve, bleibt verwundbar. Gleiches gilt für bewusst gepinnte 6.14- oder 6.17-Kernel ohne belegten Backport.

Für Hoster kommt die Konfiguration der VMs hinzu. cpu: host, explizite +vmx-/+svm-Flags oder andere CPU-Modelle können Nested Virtualization an Kunden weiterreichen. Das muss pro Produkt und VM-Konfiguration geprüft werden, nicht nur am globalen Modulparameter.

Schnelle Prüfung auf KVM- und Proxmox-Hosts

Zuerst Architektur, laufenden Kernel, KVM-Module und Nested-Status prüfen:

uname -m
uname -r
lsmod | grep -E '^kvm(_intel|_amd)?[[:space:]]'

cat /sys/module/kvm_intel/parameters/nested 2>/dev/null || true
cat /sys/module/kvm_amd/parameters/nested 2>/dev/null || true

ls -l /dev/kvm
getent group kvm

Ein Y oder 1 beim Nested-Parameter zeigt, dass der Host Nested KVM grundsätzlich erlaubt. Ob eine konkrete VM die CPU-Fähigkeit sieht, muss zusätzlich in ihrer Konfiguration und aus dem Gast geprüft werden.

# Proxmox: verdächtige CPU-Passthrough- und Nested-Konfigurationen suchen
grep -RInE '^(cpu:.*host|args:.*-cpu.*host|.*\+vmx|.*\+svm)' /etc/pve/qemu-server 2>/dev/null || true

# In einer VM: werden Virtualisierungsflags sichtbar?
grep -m1 -Eo '(^| )(vmx|svm)( |$)' /proc/cpuinfo 2>/dev/null || true

Kernel-Pakete und Härtungsoptionen prüfen:

# Debian, Ubuntu, Proxmox
dpkg -l 'linux-image*' 'proxmox-kernel*' 'pve-kernel*' 2>/dev/null | awk '/^ii/ {print $2, $3}'
apt-cache policy proxmox-kernel-7.0 proxmox-kernel-6.17 proxmox-kernel-6.14 proxmox-kernel-6.8 2>/dev/null

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

# Arch Linux
pacman -Q linux linux-lts 2>/dev/null

# Härtungsoptionen des laufenden Kernels
grep -E '^CONFIG_(DEBUG_LIST|LIST_HARDENED|BUG_ON_DATA_CORRUPTION)=' "/boot/config-$(uname -r)" 2>/dev/null || true

Ein installiertes Paket beantwortet die wichtigste Frage noch nicht. Der Abgleich endet immer wieder bei uname -r.

Mitigation und Updatepfad

Die saubere Lösung ist ein Vendor-Kernel mit belegtem Zapscape-Fix plus Reboot. Falls ein Hersteller für den verwendeten Zweig noch kein Update liefert, sollte Nested Virtualization für nicht vertrauenswürdige VMs abgeschaltet werden.

Für die nächste Modulladung lässt sich das auf klassischen Linux-Hosts vorbereiten:

printf '%s\n' 'options kvm_intel nested=0' | sudo tee /etc/modprobe.d/disable-kvm-nested.conf
printf '%s\n' 'options kvm_amd nested=0' | sudo tee -a /etc/modprobe.d/disable-kvm-nested.conf

Auf einem produktiven KVM-Host greifen diese Optionen normalerweise erst nach einem geplanten Reboot sauber, weil laufende VMs die Module belegen. KVM-Module im Betrieb gewaltsam zu entladen ist keine sinnvolle Schnellmaßnahme.

Nach der Wartung kontrollieren wir Kernel, Gast-Flags und Livepatch-Status noch einmal:

uname -r zeigt den belegten Fixkernel.
Nicht vertrauenswürdige VMs sehen kein vmx oder svm, falls der Host noch ungepatcht ist.
Ein eingesetzter Livepatch nennt CVE-2026-64561 beziehungsweise den Fix ausdrücklich. „Livepatch aktiv“ allein reicht nicht.

Nested KVM abzuschalten kann CI-Runner, Android-Emulatoren, Security-Labs oder Kunden-Hypervisoren brechen. Bei einem ungepatchten Multi-Tenant-Node ist das trotzdem oft der bessere Ausfall als ein möglicher Host-Escape.

Einordnung für Hoster und MSPs

Zapscape ist nicht für jeden Linux-Server gleich dringend. Ein Webserver ohne KVM und ohne Zugriff auf /dev/kvm hat ein anderes Risikoprofil als ein VPS-Node, der Kunden Nested Virtualization anbietet.

Auf einem Hoster-Node zählt Gast-root nicht als Schutzbarriere. Der Kunde soll seine VM administrieren dürfen. Die Barriere ist KVM selbst. Deshalb gehören Hosts mit nicht vertrauenswürdigen Gästen, aktivem Nested KVM und unbelegtem Kernel-Fix ganz nach oben in die Wartungsplanung.

OpenStack, OpenNebula, CloudStack, KubeVirt und andere KVM-basierte Plattformen erben dieses Risiko vom Host-Kernel. Ein Update des Management-Stacks repariert Zapscape nicht. Für Appliances und proprietäre Hypervisor-Produkte braucht es ein Hersteller-Advisory oder einen überprüfbaren Host-Kernelstand.

Was beim Patchen gern schiefgeht

Das neue Kernelpaket ist installiert, aber der Node wurde nicht neu gestartet.
Nur der Gast oder QEMU wurde aktualisiert.
Ein Cluster mischt Standardkernel und gepinnte Alternativzweige.
Nested KVM ist im Modul aktiv und wird über cpu: host an mehr VMs durchgereicht als erwartet.
/dev/kvm ist für lokale Benutzer, Build-Runner oder Container zu breit zugänglich.
Eine allgemeine Livepatch-Anzeige wird als Beleg für diese konkrete CVE gelesen.
Der öffentliche PoC wird auf einem produktiven Node ausprobiert. Er kann den Host beschädigen oder crashen.

Wie wir damit umgehen würden

Wir würden zuerst die KVM-Nodes mit nicht vertrauenswürdigen Gästen erfassen und dann laufenden Kernel, Nested-Status und VM-CPU-Modelle zusammen betrachten. So trennt man gefährdete Hoster-Nodes von Systemen, auf denen zwar KVM-Pakete installiert sind, aber kein realistischer Angriffspfad besteht.

Nodes mit verfügbarem Vendor-Fix bekommen ein Wartungsfenster für Migration, Update und Reboot. Fehlt der Fix, wird Nested KVM für nicht vertrauenswürdige Tarife abgeschaltet. Danach prüfen wir den Kernel aus Sicht des Hosts und die CPU-Flags aus einer Test-VM. Erst dann ist die Maßnahme abgeschlossen.

Den Zapscape-PoC würden wir nicht in Produktion ausführen. Kernelstand, Changelog und Konfiguration liefern genug Informationen für die erste belastbare Bewertung.

Update-Log

2026-07-11: Zapscape wird mit PoC an security@kernel.org gemeldet.
2026-07-21: Der Fix 2abd5287f083 wird auf der Kernel-Mailingliste veröffentlicht und in Mainline übernommen.
2026-08-04: CVE-2026-64561 wird vergeben.
2026-08-06: Embargo endet; Write-up, Exploit und Demo werden öffentlich.
2026-08-07 02:42 Uhr CEST: Artikel erstellt. Upstream-, Distro- und Proxmox-Stände geprüft, Demo lokal eingebunden.