5.7 KB/sec — the measured leakage rate the researchers report for Intel Raptor Cove chips when coaxing a root password hash out of a vulnerable kernel.
Branch Target Reuse (BTR): a revived Spectre v2 that targets JIT engines
Researchers from Vrije Universiteit in the Netherlands and Scuola Superiore Sant’Anna in Italy have published a new form of Spectre attack they call Branch Target Reuse (BTR). The team — Sander Wiebing, Yuhui Zhu, Alessandro Biondi, and Cristiano Giuffrida — describe BTR as the first practical in-place Spectre v2 attack against just-in-time (JIT) compilers. The vulnerability affects many CPUs that use speculative execution, the performance technique that executes code before it is called and that first opened the door to Spectre and Meltdown-class side channels.
How BTR hijacks speculation by reusing stale branch targets
The researchers explain the fundamental mechanism behind BTR with a specific observation about modern CPUs: "while modern CPUs restore architectural code coherence after self-modification, they do not necessarily invalidate stale indirect branch prediction entries (i.e., branch targets)." In JIT engines, these stale targets can outlive the original code and later be reused when the code cache is repopulated, the authors write, yielding what they call a speculative execute-after-free primitive. That execute-after-free behavior lets an attacker commandeer speculative control flow in ways that can evade some software defenses such as FineIBT.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleProofs of concept: Linux cBPF, GraalVM, SpiderMonkey, and leaked password hashes
The team found vulnerable code patterns in multiple JIT engines, specifically naming Linux cBPF, Oracle GraalVM, and Mozilla SpiderMonkey. They produced two proof-of-concept exploits against an Intel-based Linux kernel and showed the attack can reveal a root password hash even when the constant binding defense provided by cBPF is enabled. Measured leakage rates in those experiments were 5.7 KB/sec on Intel Raptor Cove chips and 5.4 KB/sec on Lion Cove. The researchers note the throughput is slow, but sufficient for an unprivileged user to extract a sensitive password hash from a vulnerable system.
Vendor responses: Linux kernel, Oracle, Mozilla, and assigned CVEs
Following disclosure, Linux kernel developers and Oracle implemented mitigations for the issues the researchers reported. Two CVEs were assigned to the findings: CVE-2026-64507 and CVE-2026-64508. Mozilla, the researchers say, elected a different trade-off: it has prioritized work on site isolation rather than addressing the BTR issue directly. The paper also notes that stronger mitigations such as IBPB are effective against these speculative-target attacks but carry costs — they add complexity and can hinder performance.
What this means for Linux kernel developers, Oracle, and Mozilla
- Linux kernel developers: are already moving to mitigate the specific kernel-level exploits demonstrated by the proof-of-concept code and are represented in the CVE assignments tied to the disclosure.
- Oracle: has applied mitigations to affected runtime components such as GraalVM after the disclosure, according to the researchers' timeline.
- Mozilla: has chosen to prioritize site isolation work instead of a direct fix for the BTR vector, an approach the researchers documented in their disclosure.
The Branch Target Reuse paper has been accepted for publication at the ACM Conference on Computer and Communications Security (CCS) 2026, scheduled for November 15–19 in The Hague, Netherlands. The work revives a long-running tension in microarchitecture security: defenses that block speculative side channels can be effective, but their complexity and performance impact create real operational trade-offs. BTR shows that JIT engines — used widely in browsers, runtimes, and kernels — remain fertile territory for speculative-execution attacks, and the research community, vendors, and operators now face concrete choices about where to accept performance costs in exchange for stronger guarantees.
