New Spectre v2 Variant Exposes Intel, AMD, Arm CPUs to Data Leaks

New Spectre v2 Variant Turns JIT Compilers Into a Data-Leak Launchpad

Academic researchers have disclosed a new Spectre v2 attack variant dubbed Branch Target Reuse (BTR) that exploits how modern processors handle just-in-time (JIT) compilers in web browsers, language runtimes, and operating system kernels. The technique, tracked as CVE-2026-64507 and CVE-2026-64508, was developed by Sander Wiebing, Yuhui Zhu, Alessandro Biondi, and Cristiano Giuffrida — researchers affiliated with VUSec at Vrije Universiteit Amsterdam and Scuola Superiore Sant'Anna in Italy. In proof-of-concept exploits, the team extracted a root password hash from a fully patched Intel Linux machine with default security settings enabled in as little as three minutes, and confirmed the underlying hardware flaw affects Intel, AMD, and Arm processors.

Incident Details

How Branch Target Reuse Works

The Coherence Gap Behind BTR

The vulnerability stems from a subtle inconsistency in how CPUs manage self-modifying code (SMC). As the researchers explain, "while modern CPUs restore architectural code coherence after self-modification, they do not necessarily invalidate stale indirect branch prediction entries." In other words, when a program overwrites or frees a block of executable memory and later reuses that same address for different code, the processor's Branch Target Buffer (BTB) — the hardware structure that predicts where indirect branches will jump — can still hold a prediction pointing at the old code that used to live there. No current CPU design keeps branch predictor state and code identity synchronized across that kind of reuse, which the researchers describe as a "speculative execute-after-free primitive."

Weaponizing Self-Modifying JIT Code

JIT compilers are the ideal target for this gap because they constantly allocate, discard, and reuse executable memory regions as they compile and recompile code on the fly. The attack unfolds in three stages:

1. The attacker lures the JIT engine into allocating a "training" memory chunk and forces a victim indirect branch to jump into it, planting a stale entry in the CPU's branch predictor that points to that address.
2. The attacker forces the JIT engine to free the training chunk and allocate a new "target" chunk that partially reuses the same memory address — now holding different, legitimate code.
3. The attacker triggers the same indirect branch again. Because the CPU has not invalidated the earlier prediction, it speculatively jumps to the stale training-chunk entry point instead of the correct target, momentarily executing attacker-influenced instructions before the misprediction is rolled back.

That brief speculative window is enough to leak secret data through a cache-timing side channel — the same class of technique underlying the original 2018 Spectre disclosures, but applied for the first time to code churn inside JIT engines rather than static branch mistraining alone.

From Stale Branch Targets to Root Password Hashes

The researchers built two end-to-end exploits against the Linux kernel's classic BPF (cBPF) JIT, which compiles user-supplied packet-filter bytecode into native machine code and is reachable by unprivileged processes on many systems. By walking the kernel's task list and abusing BTR to leak memory at roughly 8 bytes per second, the proof-of-concept pulled a full root password hash off a fully patched, default-configured Intel machine in about three minutes on Raptor Cove cores and five minutes on Lion Cove cores. The team also demonstrated that stale branch entries persist long enough to be reused inside Mozilla's SpiderMonkey JavaScript engine, and that Oracle GraalVM was theoretically exposed — though GraalVM's own code compilation and garbage-collection cycles happened to clear stale entries before they could be reliably exploited in testing. Notably, Intel's newest Lion Cove architecture was the only generation tested without an additional race-condition weakness layered on top of the core BTR flaw, though it remains vulnerable to the base technique.

Impact Assessment

Recommendations

For System Administrators

• Apply Linux kernel updates that address CVE-2026-64507 and CVE-2026-64508 as soon as they are available for your distribution; patches trigger an Indirect Branch Prediction Barrier (IBPB) across CPU cores whenever cBPF programs reuse freed memory.
• Restrict unprivileged BPF loading (kernel.unprivileged_bpf_disabled=1) where operationally feasible, reducing the attack surface for the demonstrated kernel exploit path.
• Track CPU microcode and firmware updates from Intel, AMD, and Arm; vendors have pointed to existing indirect-branch mitigations as a partial defense, but confirm your fleet's microcode revision is current.

For Security Teams

• Inventory workloads that rely on JIT compilation — browsers, JVM/GraalVM deployments, Node.js, and kernel BPF filters — as these represent the confirmed and theoretical attack surface for BTR.
• Coordinate with vendors of managed runtimes (Oracle GraalVM, Mozilla Firefox) on patch timelines; Oracle has begun deploying mitigations, and Mozilla is weighing IBPB-based fixes against its ongoing site-isolation work.
• Treat BTR as a reminder that Spectre-class hardware issues remain an active, evolving threat category even years after initial mitigations shipped — re-run Spectre/transient-execution exposure assessments during the next hardware refresh cycle.

For Developers of JIT/Runtime Engines

• Consider randomizing JIT code-cache memory locations rather than reusing freed addresses predictably — the approach GraalVM is adopting to hinder address reuse by an attacker.
• Where performance allows, issue an explicit branch-predictor flush (e.g., IBPB) around code-cache reuse boundaries rather than relying solely on architectural coherence guarantees.

For End Users

• Keep operating systems, browsers, and language runtimes updated; most practical mitigation for this class of flaw will arrive as OS and application patches rather than a CPU replacement.
• No user action can fully eliminate hardware-level speculative execution risk — defense in depth (updated software plus vendor microcode) remains the best available posture.

Key Takeaways

1. Branch Target Reuse (BTR) is a new Spectre v2 variant (CVE-2026-64507, CVE-2026-64508) that exploits stale branch predictor entries left behind when JIT compilers reuse freed executable memory.
2. The flaw affects Intel, AMD, and Arm processors alike, stemming from a shared architectural gap: CPUs restore code coherence after self-modification but don't necessarily invalidate stale indirect branch predictions.
3. Researchers extracted a root password hash from a fully patched, default-configured Intel Linux system in three to five minutes, leaking data at roughly 8 bytes per second via the Linux kernel's cBPF JIT.
4. Confirmed vulnerable software includes the Linux kernel's cBPF JIT, Mozilla Firefox's SpiderMonkey, and (theoretically) Oracle GraalVM.
5. Mitigation is landing primarily through software: Linux kernel patches now trigger IBPB on cBPF memory reuse, GraalVM is randomizing code-cache placement, and Firefox is evaluating IBPB-based fixes.
6. Existing Spectre v2 defenses like retpoline and standard IBPB deployment do not automatically close this gap — organizations should verify kernel and runtime patch status rather than assume prior Spectre mitigations are sufficient.

Sources

• SecurityWeek: 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
• BleepingComputer: New Spectre v2 attack variant leaks Linux root password hash in minutes