Spectre-v2 BTR attack leaks Linux root hash on patched Intel CPUs

Researchers at VUSec (VU Amsterdam) and Scuola Superiore Sant'Anna have disclosed Branch Target Reuse (BTR), a new Spectre-v2 variant that leaks memory through just-in-time compilers — and demonstrated an end-to-end exploit that recovers a Linux root password hash within minutes on a fully patched Intel system. The paper (Sander Wiebing, Yuhui Zhu, Alessandro Biondi, Cristiano Giuffrida) is accepted to ACM CCS 2026; it is the primary source, and the Linux kernel fixes are already merged.

What the bug does

Modern CPUs restore architectural code coherence after self-modification but do not necessarily invalidate stale indirect-branch-prediction entries. In a JIT engine, a code buffer gets freed and its region reused as the code cache is repopulated — yet the old branch-target predictions can outlive the code that created them. When the CPU speculates on those stale targets against freshly-written code, the result is a transient execute-after-free primitive an attacker can steer to read memory that mitigations were supposed to protect.

VUSec built working exploits against three JIT targets:

• The Linux kernel's cBPF JIT — the path used for the root-hash leak.
• Oracle's GraalVM.
• Mozilla's SpiderMonkey (the Firefox JavaScript engine).

Leak rates: about 8 bytes/second against the Linux kernel target, and an estimated dozens of bytes per second in the browser scenario. Slow, but a password hash is small.

Affected

BTR targets indirect branch prediction, so it spans vendors: the researchers name Intel, AMD, and Arm. The Intel demonstration is the headline because it bypasses all currently-enabled mitigations. The kernel side is tracked as two CVEs:

• CVE-2026-64507
• CVE-2026-64508

The Hacker News and other outlets attribute those IDs to the Linux kernel fixes; SecurityWeek's writeup of the same research did not cite a CVE. If you build inventory tooling off this, key on the kernel patch, not just the number.

Mitigation status

This is the messy part — vendors and maintainers disagree on where the fix belongs:

• Linux merged an x86 mitigation for cBPF programs; the two CVEs above are patched.
• AMD says the technique is already covered by existing Spectre-v2 guidance (IBPB).
• CPU vendors point to IBPB as an available mitigation; Intel and Arm did not comment.
• GraalVM hindered region reuse by randomizing JIT code-cache locations.
• Mozilla is prioritizing site isolation over IBPB-based mitigations for Firefox.

Action checklist

1. Apply the current Linux kernel updates covering CVE-2026-64507 / CVE-2026-64508. On multi-tenant and CI/CD hosts that run untrusted BPF or JIT workloads, this is not optional.
2. On shared or sandboxed compute, keep unprivileged eBPF/cBPF disabled where you can (kernel.unprivileged_bpf_disabled=1).
3. For browsers, treat site isolation as the load-bearing control — verify it's enabled in your managed Firefox/Chromium fleets.
4. Don't expect a microcode fix to arrive and close this: the mitigation story runs through the JIT engines and the kernel, not the silicon.

Context

BTR is the latest reminder that Spectre-v2 was never "fixed," only fenced off — and that JIT engines, which rewrite executable memory constantly, are the natural place for branch-prediction ghosts to reappear. The disagreement over whether existing guidance already covers it (AMD) or a new mitigation is required (Linux shipped one anyway) is the same standoff that has followed every transient-execution disclosure since 2018. For operators the practical takeaway is narrower: patch the kernel, and treat any host that JITs untrusted code as exposed until you have.