Live data from Hacker News

Zapscape (CVE-2026-64561): Guest-to-Host Escape in KVM/x86

github.com

11–14 of 14 posts

Re: Zapscape (CVE-2026-64561): Guest-to-Host Escape in KVM/x86

#11

Oh yay another one lol. This one seems much more general than the prior one that needed nested page tables. Patch Thursday for cloud VM ppl lol

This one exploit "shadow MMU" in the nested virtualization path of KVM, so this one is more-limited than EPT/NPT vul'n (KVM defaults to EPT/NPT, nested virt'n is disabled by default).

Nested virtualization is rather a niche feature, and, tbh, considering that shadow MMU is highly complicated legacy code (i.e. outside of the main happy path) and has been source of critical vul'n, I would avoid nested virtualization on KVM.

Re: Zapscape (CVE-2026-64561): Guest-to-Host Escape in KVM/x86

#12
Anyone know if "-cpu ${CPU},vmx=off,svm=off" in QEMU is a safe workaround for this?

(To disable nested virtualization on a per-VM basis. Only against exploitation from within that specific VM, obviously does nothing against users with access to /dev/kvm on the host.)

[That did work around Januscape: https://news.ycombinator.com/item?id=48815819]

Re: Zapscape (CVE-2026-64561): Guest-to-Host Escape in KVM/x86

#13
post #12

Anyone know if "-cpu ${CPU},vmx=off,svm=off" in QEMU is a safe workaround for this? (To disable nested virtualization on a per-VM basis. Only against exploitation from within that specific VM, obviously does nothing against users with access to /dev/kvm on the host.) [That did work around Januscape: https://news.ycombinator.com/item?id=48815819 ]

This one(Zapscape) exploits the same module(shadow MMU) as Januscape, so it does workaround the issue.

AFAIK the only code paths that activates shadow MMU are (1) lack of hardware EPT/NPT support (2) nested virtualization. Hiding `vmx`/`svm` prevents access to the second code path.

Post reply on HN