Summary
- Branch Target Reuse exploits stale branch targets that remain after JIT-generated code is removed and its memory reused.
- Researchers built end-to-end Linux cBPF exploits and observed the underlying behaviour on tested Intel, AMD, and Arm processors.
- Linux and Oracle have deployed mitigations, while Mozilla is prioritising broader site isolation for Firefox.
European security researchers have disclosed a new Spectre-v2 attack technique that exploits stale branch-prediction state in just-in-time compiled code, showing how speculative execution weaknesses can survive even when executable memory has been correctly replaced.
Researchers at VUSec at Vrije Universiteit Amsterdam and Scuola Superiore Sant’Anna in Italy call the technique Branch Target Reuse, or BTR. Their work examines JIT environments used in operating systems, browsers, and language runtimes.
The team analysed Linux classic BPF, Oracle GraalVM, and Mozilla’s SpiderMonkey JavaScript engine and built two end-to-end exploits against the Linux kernel’s cBPF JIT.
The weakness stems from a mismatch between executable code and the processor’s branch predictor. When JIT-generated code is removed and its memory reused, the code itself is updated correctly, but stale indirect branch targets can remain in prediction structures.
An attacker able to influence allocation and reuse can cause the processor to speculatively follow one of those obsolete targets into newly generated code occupying the same region. The processor eventually discards the incorrect speculative path, but sensitive information may already have influenced measurable microarchitectural state.
In the Linux demonstration, the researchers say they achieved arbitrary memory disclosure on modern Intel processors despite enabled mitigations. Their proof of concept leaked about eight bytes per second — slow in conventional data-transfer terms, but enough to recover compact secrets when the attacker can identify where to look.
The researchers also observed the underlying stale-target behaviour on every processor they tested across Intel, AMD, and Arm. That is not the same as demonstrating the same complete exploit on every processor or software stack. Practical exploitation depends on the JIT environment, attacker control over generated code, memory reuse, available gadgets, and mitigations implemented by the affected software.
In SpiderMonkey, for example, the researchers demonstrated speculative arbitrary code execution through WebAssembly-controlled data, but say turning that behaviour into a complete browser exploit requires further work.
Linux developers have already introduced mitigations. The upstream change issues an indirect branch prediction barrier when certain BPF JIT memory is reused and discourages reuse as an optimisation. CVE-2026-64507 and CVE-2026-64508 were assigned to the associated hardening work.
Oracle has taken a different approach in GraalVM by randomising JIT code-cache locations, reducing predictable reuse. Mozilla considered predictor-flushing mechanisms but is prioritising completion of site isolation in Firefox, according to the researchers.
The different responses illustrate the persistent difficulty of speculative-execution security. Processor vendors provide mechanisms software can invoke to reduce exposure, but deploying them broadly can impose performance costs and the appropriate defence depends on where untrusted code can influence speculative control flow.
The issue is most relevant where software intentionally executes user-controlled code, including browsers, language sandboxes, and kernel filtering mechanisms. Those environments rely on a strict distinction between what untrusted code can do architecturally and what the processor may transiently execute underneath it.
Branch Target Reuse does not mean existing Spectre defences have failed universally. It demonstrates another way in which predictor state can outlive the software assumptions intended to contain it, leaving mitigation largely in the hands of operating-system and runtime developers.
