Zapscape ist nach Januscape die zweite Ausbruchslücke binnen eines Monats, die der Sicherheitsforscher Hyunwoo Kim im KVM-Hypervisor des Linux-Kernels offengelegt hat. Ein Gast mit Root-Rechten schreibt damit in den Speicher des Wirts und übernimmt jede weitere virtuelle Maschine. Betroffen sind allerdings nur Hosts, die verschachtelte Virtualisierung durchreichen.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Seit dem 6. August 2026 steht der Exploit-Code zu Zapscape öffentlich auf GitHub, keine drei Wochen nach dem stillen Patch im Mainline-Kernel.[1] Verwundbar ist jede KVM-Installation seit Linux 5.9 vom Sommer 2020, geführt als CVE-2026-64561.
Das Wichtigste in Kürze
- Die Use-after-free-Lücke sitzt in der Shadow-MMU von KVM und endet mit Codeausführung im Kernel des Wirts.
- Voraussetzung ist verschachtelte Virtualisierung, auf Intel zusätzlich der Blick des Gastes auf beide EPT-Page-Walk-Längen.
- Repariert sind die Stände 6.6.148, 6.12.101, 6.18.42 und 7.1.6, alles darunter ab 5.9 bleibt offen.
- Auf Systemen mit weltweit beschreibbarem
/dev/kvmdient dieselbe Lücke einem gewöhnlichen Nutzerkonto als Weg zu root.
Wie kommt ein Gast an den Speicher des Wirts?
Die Shadow-MMU bildet in Software nach, was die Hardware bei zwei gestapelten Hypervisoren nicht mehr allein übersetzt. Jede VM darf dabei nur eine begrenzte Zahl solcher Schattenseiten belegen. Sobald das Kontingent knapp wird, räumt KVM alte Seiten ab, und dieser Aufräumpfad prüft bei rekursiv mitgenommenen Kindseiten nicht, ob dieselbe Seite gerade als aktive Wurzel dient.[1]
Diese Doppelrolle stellt der Angreifer selbst her: Eine Tabelle dient zugleich als Kind und als Wurzel zweier verschachtelter Seitentabellen. Das Aufräumen erklärt die Wurzel für ungültig, doch der laufende Seitenfehler kartiert weiter unter ihr, denn die Wurzelprüfung lief schon davor. Am Ende steht eine freigegebene Seite noch in der Liste aktiver Seiten, und der Gast schreibt in fremden Speicher.
Der Patch vom 21. Juli dreht nur die Reihenfolge um und prüft die Wurzel nach dem Aufräumen. Aufschlussreicher liest sich der Befund der Kernel-Entwickler im CVE-Eintrag: Der Fehler liegt seit 2008 im Code, scharf wurde die Konstellation erst 2020 mit der Regel, dass ungültige Seiten nie in der Liste aktiver Seiten stehen dürfen.[2] Aus derselben Shadow-MMU stammte vier Wochen zuvor der Ausbruch Januscape, im Kernel selbst steckte zuletzt die Stack-Use-after-free GhostLock.
Wen trifft Zapscape wirklich?
Verschachtelte Virtualisierung entscheidet über die Angriffsfläche. Die Kernelmodule kvm_intel und kvm_amd setzen den Parameter nested ab Werk auf 1, sichtbar wird die Technik im Gast aber erst mit durchgereichtem CPU-Flag vmx oder svm. Proxmox VE zeigt seinen VMs diese Erweiterungen in der Voreinstellung nicht.[3]
Für Hoster mit mehreren Mandanten steht damit die eigentliche Rechnung: Eine einzige gemietete Instanz reicht, um den Wirt abstürzen zu lassen oder mit Root-Rechten zu übernehmen, samt aller fremden VMs.[1] QEMU spielt keine Rolle, weil der Fehler im Kernel-KVM sitzt und jeden eigenen Virtualisierungs-Stack gleichermaßen trifft. Dass ein einziger Zugang eine ganze Plattform aufhebelt, zeigte zuletzt die Lücke CosmosEscape in Azures Cosmos DB.
Wann der Ausbruch gelingt und wann nicht
- Virtualisierungs-Flags im Gast: durchgereicht
- Rechte des Angreifers in der VM: root
- Auf AMD: keine weitere Bedingung
- Auf Intel: EPT-Walk 4 und 5 sichtbar
- Kernel: gepatchte Reihe oder neuer
- vmx- oder svm-Flag im Gast: gesperrt
- Zugriff auf /dev/kvm: eingeschränkt
- Rolle der QEMU-Version: keine
/dev/kvm für alle beschreibbar ist, genügt ein gewöhnliches Nutzerkonto für den Sprung auf root.Zapscape und Januscape stammen aus derselben Shadow-MMU, veröffentlicht im Abstand von genau einem Monat. Betreiber, die verschachtelte Virtualisierung ohne Bedarf durchreichen, verzichten auf die einzige Sperre, die ohne Neustart wirkt.
— Markus Seyfferth, Chefredakteur Dr. Web
Was sollten Betreiber jetzt prüfen?
Der Kernel-Stand zählt nach Versionsnummer, nicht nach Advisory-Datum. Lesen Sie auf jedem Host cat /sys/module/kvm_intel/parameters/nested aus und schalten Sie die Verschachtelung dort ab, wo Kunden keine eigenen Hypervisoren betreiben.
Für den Rest gehört ein Wartungsfenster in den Kalender, denn VMs mit aktivem vmx- oder svm-Flag lassen sich nicht live migrieren.[3] Der IT-Grundschutz verlangt in SYS.1.5.A2 die Prüfung von Isolation und Kapselung, in SYS.1.5.A10 die Festlegung, welche Virtualisierungsfunktionen ein Gast benutzen darf.[4] Wie zügig ein Anbieter solche Kernel-Stände nachzieht, gehört in jede Auswahl, den Vergleich der Hosting-Anbieter eingeschlossen. Die Grundlagen bündelt der Ratgeber Cybersecurity-Grundlagen.
Quellen
[1] Hyunwoo Kim: „Zapscape: Guest-to-Host Escape in KVM/x86″ mit technischer Analyse und Zeitplan der Offenlegung (6. August 2026)
[2] CVE-Eintrag des Linux-Kernel-Teams: CVE-2026-64561 mit Fehlerbeschreibung und betroffenen Versionsreihen
[3] Proxmox VE Wiki: „Nested Virtualization“ (abgerufen am 6. August 2026)
[4] Bundesamt für Sicherheit in der Informationstechnik: IT-Grundschutz-Baustein SYS.1.5 Virtualisierung, Edition 2023 (PDF)
Mehr Newshunger?
- Snowflake-Hack: Vier Jahre alte Passwörter öffneten 165 Firmenkonten
- Langflow-Lücke: IBMs KI-Baukasten vergibt Superuser-Token an jeden Aufrufer
- Atlassian Rovo: Eine versteckte Anweisung genügt für den Datenabfluss aus Jira und Confluence
- Keyv kompromittiert: Der Angriff auf die npm-Lieferkette läuft noch
- Adform kompromittiert: Ein manipuliertes Tracking-Skript ersetzte Krypto-Adressen
- Arista VeloCloud: Angreifer kapern die SD-WAN-Zentrale ohne Passwort
