Spectre v2 Attack Returns Through JIT Compilers: Branch Target Reuse, Explained
A Spectre v2 attack variant disclosed on 29 September 2026 breaks an assumption that has held since 2018. It also comes with working exploits. Researchers from VU Amsterdam’s VUSec group and Scuola Superiore Sant’Anna call it Branch Target Reuse (BTR). Their two end-to-end exploits leak the root password hash from a fully patched Intel system. The target ran default security settings, and the leak runs at eight bytes per second.
BTR’s targets are just-in-time compilers: the Linux kernel’s BPF JIT, Firefox’s SpiderMonkey, and Oracle’s GraalVM. Affected silicon spans every CPU the researchers tested — Intel, AMD and Arm.
How the Spectre v2 attack actually works this time
Spectre v2, the original 2018 branch-target-injection flaw, lets an attacker poison a CPU’s branch prediction so a victim speculatively executes attacker-influenced code. BTR narrows that old primitive to a specific blind spot.
Modern CPUs restore architectural code coherence when programs modify their own code. They do not necessarily invalidate the stale indirect branch predictions left behind, the researchers found. JIT engines constantly allocate, free and reuse code-cache memory. A stale prediction can therefore outlive the code that created it. When the engine writes new code into the freed memory, the predictor may jump execution into that new code at obsolete offsets.
The researchers call the result a speculative execute-after-free primitive. Transient control flow lands on architecturally invalid entry points, bypassing software hardening or reaching misaligned gadgets. The attack needs unprivileged code execution on the target. Classic BPF provides it on Linux: seccomp filters, socket filtering and packet filtering in Docker and Chrome still use cBPF. Unprivileged programs can load it.
What the exploits show
The kernel exploits leak arbitrary memory and bypass every enabled mitigation on modern Intel CPUs. Eight bytes per second sounds slow, but pointer chasing needs only a little leaked data to find a secret. In one demo, the researchers located a running su process and recovered the root password hash. With the kernel’s constant-blinding hardening enabled, the exploit encoded its instructions in jump offsets. It still recovered the hash within about five minutes.
Browsers face exposure in principle, but not yet in practice. In SpiderMonkey, stale branch entries persisted long enough for reuse, with an estimated leakage rate of dozens of bytes per second. A complete browser exploit does not yet exist.
In GraalVM, BTR could speculatively skip the memory masking that protects the runtime’s strictest sandbox mode. In practice, GraalVM’s own compilation and garbage collection erased stale entries before exploitation. The researchers describe that limitation as not fundamental.
The fix shipped before the announcement
Most coverage underplays one fact: the main Linux fix landed in July 2026, two months before the embargo lifted. Intel’s Pawan Gupta authored the mitigation. It triggers an Indirect Branch Predictor Barrier (IBPB) flush across every CPU core whenever cBPF code reuses memory that previously held BPF code. Daniel Borkmann and Dave Hansen acknowledged the patches.
The work carries CVE-2026-64507 and CVE-2026-64508. Stable branches already carry it — 6.1.183, 6.6.145, 6.12.97 and 7.1.4 among them. The kernel team deliberately narrowed the flush to cBPF, the unprivileged attack surface. Privileged eBPF allocations skip it, because flushing predictors on every eBPF reuse would tax busy systems for little security gain. Users running current stable kernels are therefore already protected against the demonstrated kernel attack path.
Mozilla is prioritizing the completion of site isolation over IBPB-based mitigations for SpiderMonkey. Oracle has shipped mitigations that randomize GraalVM’s JIT code-cache locations. AMD told SecurityWeek the research reveals no new vulnerability in its products, pointing to existing Spectre v2 guidance. Intel and Arm had not responded to queries at publication time.
The hardware gap no vendor has closed
CPU vendors place the fix burden on software, and the software is coping. The structural problem remains. A CPU’s branch predictor can drift out of step with the code actually in memory. No current CPU has a mechanism to keep the two synchronized. That is the researchers’ own warning, and their reason for saying every tested processor is exposed.
Hardware control-flow protections complicate exploitation without closing it. Intel’s IBT and Arm’s BTI make attacks harder, but older Intel CPUs can speculatively execute instructions before the check completes. Lion Cove is the first Intel generation free of that race. Even on race-free CPUs, the researchers bypassed IBT whenever constant blinding was off. Race-free IBT plus constant blinding is a much stronger defense, they note — but a defense, not a cure.
Eight years of Spectre, and the treadmill keeps turning
BTR belongs to a lineage. The same VUSec group broke Intel’s eIBRS and Arm’s CSV2 hardware defenses in 2022. That attack, Branch History Injection, leaked kernel memory at 160 bytes per second. The group concluded that software mitigations remained the only practical answer. Two months before BTR, MIT CSAIL researchers disclosed Interrupt Injection, another Spectre v2 defense bypass leaking kernel memory on Intel and AMD Linux systems.
The pattern across all three: each mitigation generation assumes the residual attack surface is impractical to exploit, and research then demonstrates otherwise. For eight years, researchers considered self-modifying code in commodity JITs impractical to exploit. BTR ended that assumption. Now it leaks root password hashes.
What this means for defenders
Run current stable kernels; the demonstrated kernel attack path already has a patch there. Treat unprivileged cBPF as attack surface on shared systems. Consider disabling it where workloads do not need it. Browser-based exposure remains theoretical but plausible; Firefox users benefit as site isolation matures.
Two questions remain open. Do V8, JavaScriptCore and other JIT engines share the vulnerable pattern? Will any CPU vendor commit to synchronizing prediction state with code state? Neither has an answer today. The researchers’ summary stands: until vendors add that mechanism, your CPU is vulnerable.
Editor’s Note
This article draws on the SecurityWeek report of 29 September 2026 and the researchers’ paper as quoted by The Hacker News. It also uses Phoronix’s July 2026 coverage, the CVE-2026-64507/64508 records, Linux kernel mailing-list commits, and the VUSec group’s 2022 BHI paper. Those sources supply the exploit details, leakage rates and vendor responses. TechRecast’s own analysis — the “already patched” framing and the mitigation-treadmill interpretation — appears separately above.
One finding comes straight from the researchers: every tested CPU exhibits the underlying behavior. AMD disputes the practical significance for its products. No complete browser exploit exists, and browser-based leakage rates are researcher estimates.