A team from ETH Zurich has revealed VMScape (Spectre-BTI), a speculative execution attack capable of allowing an attacker-controlled virtual machine to break isolation and extract data from the host system. Categorized as CVE-2025-40300, relies on weaknesses in the branch predictor and affects current AMD and Intel processors.
The novelty is that it works on unmodified hypervisors in default cloud configurations, targeting the KVM/QEMU stack. In their tests, the researchers managed to leak memory from the QEMU process a 32 B/s and recover sensitive secrets—including cryptographic keys—in a few 18 minutes (≈1.092 s).
VMScape exploits gaps in branch prediction
The attack is sustained in a incomplete isolation of the Branch Prediction Unit (BPU)Modern CPUs accelerate performance by anticipating jumps, but hardware barriers like eIBRS and AutoIBRS are too thick in virtualized environments and they do not distinguish finely between four key domains: HU (host user), HS (host supervisor), GU (guest user), and GS (guest supervisor).
This lack of granularity opens the door to cross-domain interference. According to the team, even with Recent improvements In next-generation processors, the isolation between GU and HU is not guaranteed unless reinforced with additional measures, leaving a loophole that can be exploited by a malicious guest.
Attack chain and exfiltration technique
Researchers describe a virtualization attack primitive for Spectre-BTI called vBTI GU→HU: an unprivileged process within the VM trains the branch predictor and manages to influence the speculation of a user process on the host (QEMU itself). Thus, after a VMEXIT, the host may end up speculatively executing a “disclosure gadget” already present in its code.
Exfiltration is performed byte by byte with the cache side channel FLUSH + RELOADTo make this feasible, the guest prepares shared memory allocated also in QEMU space, and resorts to very precise access patterns; in some scenarios it takes advantage MMIO to facilitate record control and increase filtering reliability.
A key challenge is to widen the "speculation window." The team managed to delay the resolution of the correct jump by eviction sets against Non-inclusive LLC of AMD Zen 4 and Zen 5, lengthening that critical interval and maintaining a leak rate of 32 B/s on the host's QEMU process.
The exploitation is end-to-end: in addition to the training and activation phase after VMEXIT, it includes techniques to circumvent ASLR and locate the target disclosure gadgets and regions, completing the entire route within observed time frames around the 18 minutes.
Scope and platforms affected
VMScape impacts a wide range of modern CPUs: AMD Zen 1 to Zen 5 and the family Intel Coffee LakeThe tested vector focuses on the KVM/QEMU virtualization ecosystem, which is widespread in public and private clouds, so the risk in multi-tenant environments it is not trivial.
Under these conditions, a VM with malicious intent can interfere with the state of the predictor of the host and force speculation towards existing devices, without the need to modify the hypervisor, a detail that increases the operational criticality of the vulnerability.
Available mitigations and performance costs
Following responsible disclosure, Linux kernel maintainers released patches that introduce a branch prediction barrier: IBPB in each VMEXIT just before returning to the hypervisor user space (QEMU). This clearing of the poisoned BPU state breaks the attack primitive.
To reduce the impact, the kernel applies the emptying of predictors conditionally, activating it only when necessary. Under typical loads, the measured cost is around ≈1%, although in intensive I/O scenarios it can rise significantly, with reported peaks of up to 51% according to concrete evidence.
Patches are available in Linux 6.8 and later, and it is recommended to update QEMU/KVM to versions that respect the new transition sequence. In addition, it is advisable to review deployment policies to ensure that IBPB It is systematically emitted at VM exits.
Chronology and ecosystem response
The team reported the bug to AMD and Intel PSIRTs on June 7th, 2025, under coordinated embargo until 11th September 2025During this time, we worked with the community to prepare mitigations and facilitate their adoption without intrusive changes to the hypervisors.
With the lifting of the embargo, cloud providers and on-premise administrators have been urged to apply updates without delay. In installations where hardware sharing between clients is the norm, reducing exposure time is simply critical.
Practical recommendations for security teams
Prioritize kernel upgrade to branches with IBPB-before-exit-to-userspace and verify that the production hypervisor inherits the mitigation. Where immediate upgrade is not possible, evaluate compensatory controls (isolation of sensitive loads, CPU affinity, reduction of co-location).
Strengthens observability: monitors Anomalous VMEXIT, cache miss rates, and unusual patterns in QEMU. For risk purposes, it addresses encryption keys and other infrastructure secrets such as high-value data potentially exposed on shared hosts.
In audits and threat modeling, assume that privilege-level defenses (eIBRS/AutoIBRS) can be insufficient against cross-spectrum attacks between host and guest, and documents rotation policies cryptographic material in accordance with the new scenario.
The appearance of VMScape confirms that the attack surface Speculative execution is still in effect in virtualization: a guest can force speculation on the host and leak memory with 32 B/s, but mitigations based on IBPB in VMEXIT, already present in modern Linux, allow the problem to be addressed with limited impact on most loads.