VMScape (CVE-2025-40300) brings Spectre branch target injection (Spectre-BTI) to the cloud, revealing a critical gap in how branch predictor states are isolated in virtualized environments. Our systematic analysis of protection-domain isolation shows that current mechanisms are too coarse-grained: on all AMD Zen CPUs, including the latest Zen 5, the branch predictor cannot distinguish between host and guest execution, enabling practical cross-virtualization BTI (vBTI) attack primitives. Although Intel’s recent CPUs offer better isolation, gaps still exist.
Using one of these vBTI primitives, we built an end-to-end exploit called VMScape. VMScape allows a malicious KVM guest to leak sensitive information such as encryption/decryption keys from a userspace hypervisor such as QEMU. Below you can see a demo of VMScape running on AMD Zen 4 in action.
Protection Domains
In many contexts, protection domains are simplified to supervisor (ring 0) and user (ring 3) domains, focusing on protecting the supervisor from untrusted users. However, this abstraction breaks down in virtualized environments, as we need to distinguish host and guest execution. Therefore, the user domain splits into host user (HU) and guest user (GU), while the supervisor domain comprises the host supervisor (HS) and guest supervisor (GS) domains. Ensuring confidentiality requires careful consideration of transitions between all four domains.
Broken Host-Guest Isolation
Our systematic analysis of domain isolation in virtualized environments across various microarchitectures shows that host–guest boundaries are not as well isolated as they should be.
On AMD Zen CPUs and older Intel CPUs, branch target buffer (BTB) entries lack any isolation between host and guest, causing the branch predictor to mix predictions across domains. These gaps enable us to build a number of new attack primitives that we collectively refer to as vBTI (virtualization Branch Target Injection). vBTI enables malicious actors to leak sensitive information across virtualization boundaries under different threat models that we explore in our paper. To demonstrate the feasibility of such attacks, we build VMScape, an end-to-end exploit which leaks QEMU secrets from a malicious guests on AMD Zen 4 and Zen 5.
vBHI on Intel
Intel’s eIBRS effectively isolates the BTB contents between host and guest execution. However, the mitigation does not inherently prevent a guest from (partially) controlling the branch history. While this case is mitigated for attacks against the host supervisor due to previous research, we believe that there is no mitigation for the host user. While we did not verify this, Intel has confirmed that this is indeed the case, indicating that recent Intel CPUs are potentially vulnerable to virtualization Branch History Injection (vBHI) primitives.
Mitigation
As discussed in our paper, issuing IBPB to flush the branch predictor on each VMExit would mitigate most of the vBTI primitives. Linux kernel developer developed a more efficient version of this mitigation by only issuing IBPB when the host returns to userspace. This mitigation is now available in the latest versions of the Linux kernel.
Resources
Our paper will be presented at IEEE Symposium on Security and Privacy 2026. You can find the primitives and VMScape on github.
FAQ
- Am I affected by VMScape?
Most systems are vulnerable to some vBTI primitives. Since VMScape only affects virtualized environments, systems that never run untrusted code in local VMs are not directly exploitable. Nevertheless, given the widespread use of cloud services, it is likely that you rely on infrastructure running on vulnerable hardware. - I am a sysadmin, how to secure our systems?
For Linux systems, updating to the latest version, or any maintained LTS release, is sufficient. Xen users are not affected by VMScape. For VMware, Hyper-V, or other non-KVM hypervisors, we trust that AMD and Intel have responsibly disclosed the vulnerabilities and that proper mitigations have been implemented by the respective vendors. - How is this different from earlier Spectre-BTI?
This paper presents the first systematic evaluation of branch predictor isolation across host and guest in user and supervisor modes, revealing multiple isolation gaps. Our end-to-end exploit demonstrates the impact of these gaps, as further confirmed by industry’s response in addressing these new issues. VMscape solves several additional challenges to build the first transient execution attack that targets a usermode hypervisor (i.e., QEMU). - Why bother about SMT case?
Traditional SMT Spectre-BTI attacks can only be mitigated via secure scheduling, as an adversary has no control over the scheduling of a victim thread. However with VMScape, a cross-SMT attack is facilitated, as either the attacker is in charge of scheduling (Host to Guest attackers), or because we target a thread that belongs to the same guest execution, and consequently, if more likely to get colocated (Guest to Host attackers). - Why bother about old CPUs?
We demonstrate that recent processors are vulnerable and we present our end-to-end attack on those. While older processors lose relevance over time, they are still used by cloud providers today and consequently still important in the systematic evaluation. As an example, AWS has instances with Broadwell (R4), Skylake (R5), Zen 1 (M5a), etc. - Why leaking from QEMU matters?
We built our end-to-end exploit around this scenario because it represents the strongest threat model. By leaking QEMU memory, the exploit does not just affect a single VM but directly compromises the provider’s infrastructure, clearly demonstrating the real-world impact of the discovered primitives. - Is there anything else interesting you have found?
Our reverse engineering of Zen 5 CPUs revealed an interesting change to the BTB. Each entry now carries a single-bit privilege tag, used to separate user and supervisor domains. This change effectively removes the need for AutoIBRS to defend against classical cross-privilege BTI attacks (user to supervisor). However, as VMScape demonstrates, a single bit is fundamentally insufficient to isolate the (at least) four domains present in virtualized environments.