Branch Target Reuse: A New Spectre v2 Variant Breaks JIT Compilers on Intel, AMD and Arm

Introduction

Nine years after Spectre transformed processor security in 2017, a research group in Amsterdam has found a new way to abuse speculative execution — and this time the weak point is not a single application but the just-in-time compilers that sit underneath operating system kernels, web browsers and language runtimes. Researchers from the VUSec group at Vrije Universiteit Amsterdam and Scuola Superiore Sant'Anna in Italy disclosed Branch Target Reuse (BTR) this week, describing it as a new variant of the Spectre v2 attack that reaches all three major CPU architectures. The paper is accepted at ACM CCS 2026.

The timing is significant. Chip vendors spent years hardening against Spectre-style attacks with microcode mitigations such as retpolines, IBRS and IBPB. BTR does not defeat those at the silicon level. Instead it finds a gap between what a processor promises architecturally and what its branch predictor quietly remembers, and it reaches that gap through software structures — the JIT code caches — that most hardening guidance has not considered. The Linux kernel has already received a fix, under two newly assigned CVEs, and Oracle has shipped patches. Mozilla is still working on it, which matters for anyone who browses the web on a laptop.

Main Content

The bug is a disagreement between the CPU and the compiler

The core insight, as the researchers put it, is that "while modern CPUs restore architectural code coherence after self-modification, they do not necessarily invalidate stale indirect branch prediction entries." A CPU that has self-modified its own code will make sure that subsequent instruction fetches see the new bytes — the architectural state stays coherent. But the indirect branch predictor, a separate hardware structure that guesses where a computed jump will land, is not obliged to be told. Its stale entries can survive.

A JIT compiler makes that gap exploitable by design. It allocates a chunk of memory for generated code, trains the branch predictor by executing an indirect branch into that chunk, frees the chunk, and then allocates a different program into overlapping memory. The predictor still holds a branch target buffer entry pointing at the old entry point. The next time the branch executes, the CPU speculatively jumps to an address that, architecturally, is no longer the start of anything. The researchers call this a speculative execute-after-free primitive: control flow is redirected to an offset that is invalid at the architectural level but perfectly usable while speculation is in flight.

The attack sequence the VUSec team documents is five steps. An attacker lures the JIT engine into allocating a training chunk, and jumps to it to poison the branch target buffer. The attacker then forces that chunk to be deallocated, and allocates a target chunk that partially reuses the same address. Triggering the indirect branch again makes the CPU follow the stale entry, speculatively landing inside the new code at the old offset. Because that offset is misaligned relative to the new code's real instruction boundaries, bytes that were encoded as ordinary data or jump offsets get decoded and executed as instructions. That is how a data-only allocation becomes attacker-controlled speculative code.

What was actually broken, and how badly

The team analysed three JIT targets, each with what they describe as "markedly different exploitability characteristics and leakage rates." They are Linux cBPF, Oracle's GraalVM runtime, and SpiderMonkey, the JavaScript and WebAssembly engine underneath Firefox.

The Linux kernel was the most severe result, and it is the one that received working end-to-end exploits. The researchers built two of them. Both create a pair of cBPF programs — a training program and a target program — and install them as seccomp filters. The more capable eBPF JIT is restricted to privileged users, but cBPF is intentionally tiny and still reachable by unprivileged programs; seccomp, socket filtering, and packet filtering in applications such as Docker and Chrome all continue to rely on it. That makes it an unusually broad attack surface for what sounds like a narrow kernel feature.

In the demonstration, the exploit walks the Linux kernel's task list backwards by leaking each prev pointer, locates the target process's task struct, follows the mm struct into the page tables, and extracts the root password hash once the correct page is found. The researchers are explicit that the leak rate is only 8 bytes per second, but they note that with careful pointer chasing an attacker only needs to leak a small amount of data to reach a secret. "Our exploit leaks arbitrary memory on modern Intel CPUs, bypassing all enabled mitigations," they write. The demonstrations recovered the root hash from a fully patched system with default protections enabled.

The interesting part for defenders is that they went further than the default configuration. The bpf_jit_harden option applies constant blinding to immediate values specifically to stop JIT spraying. It is off by default. The team took on the challenge of defeating it anyway, adapting a technique from Maisuradze and colleagues (2016) that hides attacker-controlled bytes in the offset fields of forward jumps rather than in immediates. Because the maximum forward jump offset is 0x014fc5, only the lower two bytes are controllable, so instructions must be chosen carefully to keep execution in the misaligned stream. They report a working end-to-end exploit against cBPF with blinding enabled.

Why mitigation is a software problem

Asked directly whether this is most likely to be fixed in hardware, the researchers' answer is blunt: "No current CPU has a mechanism to keep the two in sync, so until vendors add one, your CPU is vulnerable." They confirmed the underlying behaviour on every CPU they tested, across Intel, AMD and Arm. Mitigation is left to software.

Linux has already moved. Kernel developers upstreamed an x86 mitigation that issues an indirect branch predictor barrier (IBPB) on all cores whenever a cBPF program reuses a region that previously held cBPF or eBPF code, and they discouraged such reuse as an optimization. The mitigation applies whether or not indirect branch tracking is enabled. Two CVEs were assigned: CVE-2026-64507 (x86/bugs: Enable IBPB flush on BPF JIT allocation) and CVE-2026-64508 (bpf: Support for hardening against JIT spraying).

Oracle took a different route with GraalVM, randomising JIT code-cache locations so that region reuse becomes impractical. Mozilla considered IBPB-based mitigations for SpiderMonkey but is prioritising completion of site isolation, which matters because until that rollout completes, content from other tabs may share an address space with an attacker's page.

The researchers are careful not to overstate the result. BTR "raises the bar, but does not eliminate the risk." Indirect branch tracking on x86 and branch target identification on Arm require indirect branch targets to begin with an endbr64 or BTI instruction, but on older Intel CPUs one or more instructions can still execute speculatively before that check — Lion Cove is the first race-free generation the team found. Even on race-free implementations, they note an attacker can inject bytes into JIT-compiled code that encode endbr64 and reach them through misaligned execution, turning attacker data into a valid landing pad. They were only able to do this with constant blinding disabled, which is why they consider race-free indirect branch tracking combined with constant blinding a much stronger defense.

Conclusion

Branch Target Reuse is a reminder that the Spectre class of bugs does not end with microcode. The mitigation race for the original vulnerabilities was won, in the sense that silicon-level defenses landed and hold. What BTR shows is that a class of software structures — just-in-time compilers, which every modern browser, every language runtime and the kernel itself depend on — was never audited for the assumption the microcode fixes rest on. That assumption is that architectural state and predictor state stay in agreement after code changes. In a JIT engine, they reliably do not.

For operators the practical path is straightforward and unglamorous. Update promptly: the Linux kernel and Oracle have both released fixes, and the two CVEs are the tracking identifiers to watch. Treat the Mozilla case as unresolved rather than low-risk, since an attacker who reaches a browser JIT does not need privileged code, only a page the victim visits. And if you run seccomp filters or containerised workloads that lean on cBPF, that is the surface where this attack is most concrete today.

The longer-term question is whether CPU vendors will add a mechanism to keep predictor state synchronized with code, which is what would close the whole family rather than individual instances. On the researchers' assessment, that mechanism does not exist yet. Until it does, the next variant is a matter of time rather than design.

Images

References

• VUSec, "Spectre-v2 Attacks in JIT Engines — Branch Target Reuse" (CCS 2026): https://www.vusec.net/projects/btr/
• SecurityWeek, "New Spectre v2 Variant Exposes Intel, AMD, Arm CPUs to Data Leaks": https://www.securityweek.com/new-spectre-v2-variant-exposes-intel-amd-arm-cpus-to-data-leaks/
• The Hacker News, "New Spectre-v2 BTR Attack Leaks Linux Memory Despite Existing Defenses": https://thehackernews.com/2026/09/new-spectre-v2-btr-attack-leaks-linux.html
• CVE-2026-64507 and CVE-2026-64508, Linux kernel x86/BPF JIT mitigations
• Linux kernel documentation, bpf_jit_harden

Related coverage on this site: readers following processor-level risk may also want our Semiconductors coverage, and those tracking defensive tooling should see Cybersecurity analysis of the month's exploit disclosures.