Beheerders van Linux KVM-hosts krijgen met Zapscape KVM-kwetsbaarheid (CVE-2026-64561) een duidelijke reden om hun systemen snel te controleren en te updaten. Het gaat om een fout in de KVM-shadow-MMU logica, die kan leiden tot een escape vanuit een geprivilegieerde L1-guest naar de host.
In deze situatie beschikt een aanvaller in de L1-virtual machine over kernelprivileges. Dat klinkt als een “lastige” voorwaarde, maar juist wanneer nested virtualisatie wordt aangeboden aan niet-vertrouwde gasten, wordt het scenario realistischer voor omgevingen zoals hosting, publieke clouds of multi-tenant setups.
Wat is de Zapscape KVM-kwetsbaarheid?
De Zapscape KVM-kwetsbaarheid is een Linux kernelprobleem dat specifiek betrekking heeft op KVM/x86 shadow memory management (shadow-MMU). Deze MMU beheert shadow page tables voor het vertalen van geheugen van nested guests.
De fout is door securityonderzoeker Hyunwoo Kim openbaar gemaakt en valt in de categorie “use-after-free” gerelateerd aan een volgorde-check in KVM’s boekhouding van shadow-MMU-pagina’s. Door die volgordefout kan KVM doorgaan met een reeds ongeldig gemaakte root van de shadow-MMU.
Kim beschrijft daarbij een exploitpad waarmee commando’s op de host kunnen worden uitgevoerd met kernel- of rootrechten. Daarmee gaat het dus om echte code-uitvoering op het hostniveau, niet enkel om een crash of denial of service.
Wanneer ontstaat het risico?
De kwetsbaarheid raakt KVM-hosts die nested virtualization beschikbaar stellen aan L1-gasten. Een belangrijk vereiste is dat de aanvaller in de L1-guest kernelprivileges heeft—praktisch gezien komt dat meestal neer op root in die L1-guest.
Daarnaast noemt de melding voorwaarden voor Intel-systemen: daar moeten ook specifieke EPT-instellingen (page-walk lengtes 4 en 5) zichtbaar zijn voor de L1-guest. Voor AMD noemt de advisering geen equivalent van die Intel-voorwaarde.
De kern: als je nested virtualisatie blootstelt aan gasten die je niet vertrouwt, dan wil je er rekening mee houden dat een “compromised” L1-guest kan proberen om de KVM-isolatie te omzeilen.
Hoe werkt de fout in het kort?
Volgens de technische beschrijving draait het om de afhandeling van page faults in KVM. Tijdens die afhandeling kan KVM MMU-pagina’s terugwinnen (reclaim) en daarbij de shadow-MMU root ongeldig maken die nog in gebruik is door het pad dat de fault afhandelt.
Het probleem ontstaat doordat het pad de root daarna niet opnieuw controleert. Daardoor blijft KVM doorgaan alsof de root nog geldig is, terwijl die ondertussen is geïnvalideerd.
In de publicatie wordt het scenario uitgewerkt als use-after-free in een “recursive zap path” waarin KVM pagina’s kan terugnemen. Daarbij kan later cleanup ertoe leiden dat dezelfde koppeling dubbel wordt gebruikt en pagina’s worden vrijgegeven terwijl er nog verwijzingen bestaan. Dat levert uiteindelijk het mechanisme om een keten op te bouwen naar host-niveau acties.
CVE-2026-64561 en proof-of-concept
De Zapscape KVM-kwetsbaarheid is gelabeld als CVE-2026-64561. In de openbaarmaking is een proof-of-concept gedeeld waarmee Kim aantoont hoe je het primitieve use-after-free mechanisme kunt inzetten om op de host een wortel-gedreven bestand te creëren, aangeduid als /Zapscape.
De PoC richt zich op AMD nested SVM/NPT op Linux kernel 7.1.3. Kim adviseert om dit soort testen veilig uit te voeren onder QEMU TCG, en benadrukt dat QEMU niet de kwetsbare component is. Het probleem zit in de in-kernel KVM-logica en wordt onafhankelijk van de emulatie geactiveerd.
Belangrijk voor de praktijk: de publicatie claimt niet dat de kwetsbaarheid al actief is misbruikt “in het wild”. Ook wordt het probleem door Kim omschreven als geen “onmiddellijk wapenbaar” exploit in cloudcontexten. Voor echte aanvallen zou men acties in een guest kernel module moeten verplaatsen en de exploit moeten afstemmen op hostconfiguraties en geheugen-achtergronden.
Wat is de impact voor Linux KVM-hosts?
Als de voorwaarden kloppen en een aanvaller via een gecompromitteerde L1-guest erin slaagt om de benodigde triggers te veroorzaken, dan kan KVM host-code uitvoeren met host kernel/root privileges. Dat betekent dat de isolatie tussen gast en host niet langer gegarandeerd is.
De impact is dus hoog, omdat het gaat om een escape uit virtualisatiegrenzen. Daarbij is het risico niet “standaard voor alle KVM-hosts”, maar juist relevant wanneer je nested virtualisatie aanbiedt aan omgevingen of klanten waar je niet volledig controle over hebt.
Fix en updatestatus: wat moeten beheerders doen?
De upstream fix is inmiddels opgenomen. De publicatie meldt dat beheerders moeten updaten naar een gefixte stabiele kernel of een vendorpakket waarin de patch is teruggeporteerd.
De wijziging in de fix draait om het moment waarop een “stale-root” check plaatsvindt. De patch verplaatst de check naar na make_mmu_pages_available(). Als reclaim de huidige root ongeldig maakt, start KVM de fault-handling vervolgens opnieuw met RET_PF_RETRY, in plaats van door te gaan onder een ongeldig geworden root.
Let op: pakketstatus hangt af van de Linux-distributie en vendor backports. Een distributie kan security-updates leveren met teruggeporteerde fixes zonder dat de kernel “officieel” versienummer-matig overeenkomt met upstream.
Welke kernels/distributies zijn gemeld als kwetsbaar?
De National Vulnerability Database (NVD) vermeldt dat Linux 5.9 en later kwetsbaar is tot een gefixeerde stabiele release. Daarbij worden expliciet enkele fixed stable versies genoemd, waaronder 6.6.148, 6.12.101, 6.18.42 en ook 7.1.6. Daarnaast wordt 7.2-rc5 genoemd in de lijst.
Red Hat heeft in de advisering een voorlopige CVSS-score van 7.0 gegeven en de kwetsbaarheid ingedeeld als CWE-825 (expired pointer dereference). Tegelijk wijst Red Hat erop dat backports mogelijk zijn zonder rebasing naar nieuwere upstreamversies.
Per 6 augustus 2026 vermeldde Debian’s tracker ook kwetsbare kernelpakketten binnen de relevante branches, met specifieke aandacht voor de security repositories van bullseye, bookworm en trixie. Daaruit volgt dat je als beheerder niet alleen naar “branchnamen” moet kijken, maar naar de concrete pakketstatus van je distributie.
Release- en disclosure-timeline
Volgens de disclosurelijn begon de rapportage op 11 juli 2026, toen Kim contact opnam via security@kernel.org. Op 21 juli werd de patch gepost en gemerged, waarna de issue op 1 augustus op een linux-distros mailinglist werd gedeeld met een embargo van vijf dagen.
Op 4 augustus werd CVE-2026-64561 toegewezen, waarna de publieke bekendmaking op 6 augustus 2026 volgde.
Praktische check: nested virtualisatie inventariseren
Omdat het scenario specifiek nested virtualisatie vereist, is een snelle aanpak voor teams meestal: inventariseer waar je nested virtualization aan hebt staan en waar L1-gasten mogelijk niet volledig vertrouwd zijn.
- Check KVM-hostinstellingen en documenteer welke tenants of omgevingen nested virtualisatie gebruiken.
- Werk kernels bij naar een pakket met de backport van de fix, of naar een kernelversie die de upstream patch bevat.
- Beperk exposure: als je nested virtualisatie niet strikt nodig hebt voor niet-vertrouwde gasten, zet het uit of scheid omgevingen.
Als je veel met governance, compliance en risk management rond cyberincidenten doet, helpt het ook om dit soort kernel-issues mee te nemen in je structurele proces. Zie bijvoorbeeld ook de achtergrond bij Bron: https://thehackernews.com/2026/08/new-zapscape-kvm-flaw-could-let.html
