Recente ontdekking van een nieuwe, kritieke kwetsbaarheid in het KVM/x86 subsysteem van de Linux-kernel brengt de beveiliging van hypervisors gebaseerd op deze technologie opnieuw in het nieuws, waaronder Proxmox VE. Deze bug, gekend als CVE-2026-64561 en aangeduid als Zapscape, maakt onder bepaalde omstandigheden het mogelijk dat een virtuele machine ontsnapt naar de host en code met kernelprivileges uitvoert.
Samenvatting van Zapscape in 20 seconden
- De kwetsbaarheid CVE-2026-64561 betreft het KVM/x86 subsysteem van de Linux-kernel.
- Het stelt een mogelijke escape van virtuele machine naar host mogelijk via een fout in Shadow MMU.
- De exploitatie vereist dat de gastgebruiker hoge privileges heeft en dat nested virtualization actief is.
- Proxmox VE en andere KVM-gebaseerde platformen dienen zodra updates beschikbaar zijn de kernel te patchen.
Deze kwetsbaarheid is ontdekt door onderzoeker Hyunwoo Kim (@v4bel), die zowel de technische analyse heeft gepubliceerd als een proof of concept (PoC) nadat het embargo met de Linux-kernelontwikkelaars werd opgeheven.
De kern ligt bij KVM, niet bij Proxmox VE
Hoewel het nieuws veel admins van Proxmox VE bezorgt, is het belangrijk te verduidelijken dat de kwetsbaarheid niet in Proxmox zelf zit, maar in KVM (Kernel-based Virtual Machine). Dit hypervisor-onderdeel, ingebouwd in de Linux-kernel, wordt gebruikt door talloze virtualisatieplatformen.
Hierdoor is de impact veel breder dan alleen Proxmox VE en kan het ook systemen beïnvloeden zoals:
- Aangepaste KVM-omgevingen.
- Cloud-platformen gebaseerd op KVM.
- Virtuele oplossingen die KVM als motor gebruiken.
- Linux-distributies die KVM aan externe gebruikers of providers blootstellen.
De auteur geeft aan dat het probleem zich bevindt in de Shadow MMU van KVM/x86, specifiek tijdens het terughalen van geheugenpagina’s in gevallen van nested virtualization.
Wat is Zapscape precies?
Volgens de technische documentatie is Zapscape een Use-After-Free (UAF) kwetsbaarheid.
Tijdens bepaalde bewerkingen in Shadow MMU verwijdert KVM recursief een wortelpagina die nog in gebruik is, waarna verdere operaties plaatsvinden op een al vrijgegeven structuur. Hierdoor kan geheugencorruptie op de host-kernel ontstaan.
Een geslaagde aanval zou kunnen leiden tot het uitvoeren van code met root-privileges op de host.
Wat is de impact?
Het technische rapport beschrijft twee voornaamste scenario’s:
Ontsnappen van een VM naar de host
Het meest zorgwekkend voor cloudproviders.
Een cliënt met controle over haar VM zou de fysieke server kunnen compromitteren en mogelijk ook andere virtuele machines op dezelfde host aantasten.
Mogelijke gevolgen omvatten:
- Externe uitvoering van code op de host;
- Denial of Service (DoS);
- Compromittering van andere VM’s.
Lokale privilege-escalatie
In sommige Linux-distributies waarbij /dev/kvm zonder hoge privileges toegankelijk is, kan de kwetsbaarheid ook worden gebruikt voor lokale privilege-escalatie tot beheerder.
Zijn alle Proxmox-installaties kwetsbaar?
Het is belangrijk te benadrukken dat het feit dat deze kwetsbaarheid bestaat niet automatische betekent dat iedere installatie gecompromitteerd kan worden.
Volgens de onderzoeker vereisen succesvolle exploitatie meerdere condities:
| Vereiste | Benodigd? |
|---|---|
| Kwetsbare KVM/x86 | Ja |
| Nested virtualization | Ja |
| Root privileges binnen VM | Ja |
| Specifieke Shadow MMU-configuratie | Ja |
Met andere woorden, een thuis- of zakelijke installatie die geen nested virtualization toestaat voor onbetrouwbare gebruikers, loopt een veel lager risico dan een multi-gebruiker cloudomgeving.
Affecteerde versies
De onderzoeker geeft aan dat de kwetsbaarheid zich bevond in code tussen de volgende commits:
- Vanaf f95eec9bed76 (8 juli 2020).
- Tot 2abd5287f083 (21 juli 2026).
Dit wijst erop dat het probleem al zes jaar bestaat en tot op heden in verschillende kernelversies aanwezig was, totdat het werd opgelost.
QEMU is niet de boosdoener
Een ander belangrijk punt dat uit de documentatie blijkt is dat QEMU niet deze kwetsbaarheid bevat.
De zwakte ligt volledig in KVM binnen de Linux-kernel, en dus ongeacht de virtualisatiesoftware die wordt gebruikt door de systeembeheerder.
Dit betekent ook dat elke platform dat KVM als backend inzet, de kernel-updates moet toepassen zodra die beschikbaar zijn, los van welke versie QEMU draait.
Wat moeten Proxmox-beheerders doen?
Terwijl distributies hun patches uitbrengen, wordt aanbevolen om de gebruikelijke veiligheidsmaatregelen te volgen:
- De kernel zo snel mogelijk bijwerken zodra patches beschikbaar zijn;
- Het gebruik van nested virtualization beperken tenzij strikt noodzakelijk;
- Toegang tot /dev/kvm beperken tot bevoegde gebruikers;
- De adviezen van Proxmox en de gebruikte Linux-distributie opvolgen.
Zoals bij de meeste KVM-kwetsbaarheden hangt het risico sterk af van het bedreigingsmodel. Cloudomgevingen met meerdere huurders en onbetrouwbare VM’s vormen de potentiële risicogroup.
Nieuwe waarschuwing voor cloudoperators
Zapscape verschijnt enkele maanden na Januscape (CVE-2026-53359), een andere kwetsbaarheid in hetzelfde Shadow MMU-systeem van KVM. Hoewel de onderzoeker stelt dat beide problemen een andere oorzaak hebben, benadrukt hij dat deze fouten het belang onderstrepen van duurzame update-processen voor hypervisors.
De publicatie van een werkende proof of concept onderstreept de urgentie dat beheerders en cloudproviders snel de gepatchte versies uitrollen zodra die beschikbaar zijn.
Veelgestelde vragen
Heeft deze kwetsbaarheid directe impact op Proxmox VE?
Nee. Het probleem zit in KVM/x86, de hypervisor binnen de Linux-kernel die onder andere Proxmox VE aandrijft en die door vele andere platformen wordt gebruikt.
Kan een VM ontsnappen naar de fysieke server?
Ja, onder bepaalde condities kan de kwetsbaarheid het mogelijk maken om de host te compromitteren vanuit een met hoge privileges uitgeruste VM.
Is QEMU ook kwetsbaar?
Nee. De technische documentatie bevestigt dat het probleem zich uitsluitend in KVM binnen de Linux-kernel bevindt en niet in QEMU.
Wat moeten beheerders doen?
De kernel patchen zodra beschikbaar, het gebruik van nested virtualization beperken indien niet strikt noodzakelijk en de beveiligingsadviezen van de distributie en de hypervisorleverancier opvolgen.