Die KVM-Escape-Trilogie

ITScape (CVE‑2026‑46316)

Januscape (CVE‑2026‑53359)

Zapscape (CVE‑2026‑64561)

Zapscape: Guest-to-Host-Escape in KVM/x86

Zusammenfassung

Dieses Dokument beschreibt die Zapscape (CVE-2026-64561)-Sicherheitslücke, die von Hyunwoo Kim (@v4bel) entdeckt und gemeldet wurde. Es handelt sich um eine KVM-Escape-Schwachstelle, die es einem Gast ermöglicht, in einer KVM/x86-Umgebung auf den Host zu entkommen und dort Befehle mit Kernel-(Root-)Rechten auszuführen.

Zapscape ist eine Use-after-Free-Schwachstelle in der Shadow-MMU-Emulation von KVM/x86, genauer gesagt im rekursiven zap-Pfad, der ausgeführt wird, wenn Shadow-Seiten freigegeben werden. Sie lässt sich allein durch Aktionen auf der Gastseite auslösen, um die Shadow-Seite des Host-Kernels zu korrumpieren, und kann die Gast-Host-Isolation von KVM/x86-Hosts gefährden, die nicht vertrauenswürdige Gäste akzeptieren und verschachtelte Virtualisierung bereitstellen – insbesondere Multi-Tenant-x86-Public-Clouds.

Ausführliche technische Informationen finden Sie hier.

[!NOTE] Nach der Meldung dieser Sicherheitslücke an [email protected] ist die vereinbarte Sperrfrist abgelaufen, sodass der Exploit auf oss-security veröffentlicht und dieses Zapscape-Dokument publiziert wurde. Den zeitlichen Ablauf der Offenlegung finden Sie im technischen Detaildokument.

PoC-Struktur

Der PoC ist auf AMD ausgelegt; für sichere Tests wird empfohlen, ihn unter QEMU TCG auszuführen. Der PoC hat die folgende Struktur.

L0: Linux 7.1.3 + KVM_AMD on an x86_64 CPU (AMD SVM/NPT) emulated by QEMU TCG. The escape target
  └─ L1: the guest poc creates. Switching long -> PAE aliases one shadow page as both child and pinned root, and L1 then escalates the UAF into L0 kernel code-exec
       └─ L2: the guest L1 VMRUNs. Its memory touches trigger L0's quota reclaim -> recursive zap with no root_count guard -> UAF

Dieser PoC ist kein ausgereifter Exploit, der sofort in einer Cloud-Umgebung läuft, sondern Demonstrationscode, der die Schwachstelle und die vollständige Exploit-Kette auf Basis von QEMU TCG reproduziert. Um ihn in einer echten Cloud-Umgebung einzusetzen, müssen die vom PoC durchgeführten L1-Aktionen in ein Gast-Kernelmodul verlagert und der Exploit an das kconfig des Host-Kernels angepasst werden. Das ist keine schwierige Aufgabe.

Verwendung des PoC

1. Laden Sie den Quellcode des verwundbaren Kernels v7.1.3 herunter und erstellen Sie dann das Kernel-Image auf Basis des beiliegenden kconfig.
2. Bauen Sie den PoC, stellen Sie dann mit BusyBox oder Ähnlichem ein passendes initramfs zusammen und legen Sie den gebauten PoC in das initramfs.

# gcc -O2 -g -static -pthread poc.c -o poc

3. Booten Sie das Zielsystem (Linux 7.1.3) mit dem folgenden Befehl. Testen Sie auf QEMU v9.2.0 oder neuer.

# ./qemu.sh bzImage initramfs.cpio.gz

4. Führen Sie den PoC aus, nachdem QEMU TCG gebootet ist. Bei einem erfolgreichen Exploit entkommt er dem Gast und erstellt die Datei /Zapscape im Besitz von root auf dem Host.

 /$$$$$$$$  /$$$$$$  /$$$$$$$
|_____ $$  /$$__  $$| $$__  $$
     /$$/ | $$  \ $$| $$  \ $$
    /$$/  | $$$$$$$$| $$$$$$$/
   /$$/   | $$__  $$| $$____/
  /$$/    | $$  | $$| $$
 /$$$$$$$$| $$  | $$| $$
|________/|__/  |__/|__/

[+] /Zapscape created by the target KVM host kernel (owner uid=0, mode=0644).
[+] exploit completed - verify with: ls -la /Zapscape
zapscape(uid=65534)$ ls -la /Zapscape
-rw-r--r--    1 root     root             0 Jul 29 05:27 /Zapscape
zapscape(uid=65534)$

Dieser PoC dient dazu, genaue Informationen bereitzustellen. Verwenden Sie ihn nicht auf Systemen, für die Sie nicht zum Testen autorisiert sind.

Betroffene Versionen

Zapscape (CVE-2026-64561) betrifft den Bereich von f95eec9bed76 (2020-07-08) bis 2abd5287f083 (2026-07-21).

FAQ

Welche Auswirkungen hat diese Schwachstelle?

Dieselben wie bei Januscape (CVE-2026-53359):

1. KVM-Escape: Allein durch Aktionen auf der Gastseite kann ein Angreifer den Host kompromittieren, auf dem seine VM läuft. Beispielsweise könnte ein Angreifer, der lediglich eine einzige Instanz in einer öffentlichen Cloud gemietet hat, den Host-Kernel zum Absturz bringen (Panic), um alle anderen Mandanten-VMs auf derselben physischen Maschine lahmzulegen (DoS), oder Code mit Root-Rechten auf dem Host ausführen, um den Host und alle darauf laufenden Gäste zu übernehmen (RCE).
2. LPE: Auf Distributionen wie RHEL ist /dev/kvm für alle Benutzer beschreibbar (0666), sodass ein unprivilegierter Benutzer diese Schwachstelle auch als LPE nutzen kann, um Root-Rechte zu erlangen. Bei der Verwendung als LPE stehen hostseitige VMM-ioctls zur Verfügung, wodurch der Exploit einfacher und stabiler wird.

In welchem Zusammenhang steht dies mit Januscape?

Sie tritt in derselben Shadow-MMU auf, ist aber eine eigenständige Schwachstelle mit einer anderen Ursache.

Allerdings kann sie – anders als Januscape – auf Intel nur ausgelöst werden, wenn L1 sowohl die EPT-Page-Walk-Länge 4 als auch 5 zur Verfügung gestellt werden. Dies ist ein wichtiger Punkt bei der Bewertung des betroffenen Bereichs und muss daher genau verstanden werden. Siehe das technische Detaildokument.

Tritt diese Schwachstelle in QEMU auf?

Nein. Wie bei Januscape tritt sie im kernelbasierten KVM auf und wird daher unabhängig von der Emulation durch QEMU ausgelöst. Aus diesem Grund kann sie auch große öffentliche Clouds gefährden, die einen eigenen Virtualisierungs-Stack implementieren und einsetzen.

Benötige ich Root-Rechte innerhalb der Gast-VM?

Ja. Es sind Kernel-Rechte auf L1 erforderlich. Wenn Ihnen eine Instanz in einer öffentlichen Cloud zugewiesen wird, haben Sie in der Regel Root-Rechte auf Ihrer eigenen VM, sodass diese Voraussetzung erfüllt ist. In einem Szenario ohne Root im Gast muss sie mit einem LPE wie Dirty Frag kombiniert werden.

Glauben Sie, dass KVM-Sicherheitslücken weiterhin auftreten werden?

Ja. Ich empfehle, einen nachhaltigen Patch-Prozess für Host-Hypervisoren zu etablieren. Der Winter kommt.

Planen Sie nach der Trilogie eine Fortsetzung?

Ich hoffe nicht.