Spectre v2 Branch Target Reuse vulnerability

Researchers disclosed a new Spectre v2 Branch Target Reuse vulnerability on September 29 that lets an attacker recover a Linux system’s root password hash in minutes, on a fully patched Intel machine, by abusing a gap between how CPUs and just-in-time compilers handle recycled memory. The flaw touches Intel, AMD and Arm processors alike, and no patch closes it at the hardware level.

What Happened

Academics from VUSec (VU Amsterdam) and Scuola Superiore Sant’Anna published “Branch Target Reuse” (BTR), a new variant of the 2018 Spectre v2 CPU attack family. Every modern processor uses branch prediction to guess where a program will jump next and speculatively execute code along that guess. BTR exploits a subtle inconsistency: when a just-in-time (JIT) compiler frees a block of compiled code and later reuses that exact memory address for new code, the CPU correctly restores normal program behavior, but does not reliably clear the branch predictor’s memory of what used to live at that address. An attacker who can make a JIT engine allocate, free and reallocate code at a chosen address can trick the CPU into speculatively jumping to the old, defunct code instead of the real target, then read out secrets through the well-known cache-timing side channel.

The researchers confirmed the underlying hardware behavior on every Intel, AMD and Arm CPU they tested, and built two working exploits against the Linux kernel’s classic BPF (cBPF) filtering engine, used in seccomp sandboxing and packet-filtering paths inside software such as Docker and Chrome. Their published proof of concept walks the Linux kernel’s internal process list and recovers the root account’s password hash from a fully patched, default-configured Intel system within minutes, leaking roughly 8 bytes of memory per second. Mozilla’s Firefox JavaScript engine (SpiderMonkey) and Oracle’s GraalVM runtime were also shown to be exploitable in principle, at lower leakage rates the researchers describe as a matter of further engineering, not a fundamental barrier.

CPU vendors told the researchers that existing hardware mitigations, such as the Indirect Branch Predictor Barrier (IBPB), already exist and that BTR needs to be closed in software. The Linux kernel has since shipped a fix, tracked as CVE-2026-64507 and CVE-2026-64508, that forces an IBPB flush whenever a classic or extended BPF JIT region is reused. Oracle’s GraalVM mitigates the issue by randomizing where its JIT compiler places code in memory. Mozilla says it is prioritizing the rollout of full site isolation in Firefox over an interim IBPB-based patch.

Why It Matters

The Spectre v2 Branch Target Reuse vulnerability is not a single product with a single patch. It is a gap in how CPU branch prediction hardware interacts with any JIT compiler, and JIT compilers sit inside nearly every modern browser, container runtime and server-side language platform a German Mittelstand IT estate runs. Eight years after Spectre was first disclosed, BTR is a clear reminder that the category was never fully closed at the silicon level. Every mitigation shipped since 2018, including this one, has been a software or firmware workaround layered onto hardware that was not designed with this threat model in mind. For a CISO, the practical exposure today is narrower than the demonstration suggests: an attacker needs a way to run code inside a vulnerable JIT engine on the target system, which typically means either local access or a means of running attacker-controlled code in a browser or container. But “CPU-level, needs a vendor microcode or kernel fix” issues are exactly the category that patch-management programs tend to deprioritize, and BTR is a concrete argument for treating them with the same urgency as any other critical vulnerability.

What You Should Do Now

1. Update Linux kernels to a version carrying the fixes for CVE-2026-64507 and CVE-2026-64508 as soon as your distribution ships them, and prioritize this on any host running containers, browsers, or other software that JIT-compiles code from untrusted input.
2. Check whether bpf_jit_harden is enabled on your Linux hosts as defense-in-depth; note that the researchers also demonstrated a bypass of this specific hardening option, so treat it as one layer, not a substitute for the kernel patch.
3. Track Mozilla’s mitigation timeline for Firefox specifically; until full site isolation or an equivalent fix ships, browser-based JIT exposure to BTR-style attacks remains open on affected systems.
4. If you run Oracle GraalVM as a sandbox for untrusted guest code (plugins, user-supplied scripts), confirm you are on a version that includes the JIT code-cache randomization mitigation before relying on that sandbox boundary.

If any of these steps depend on vendor guidance that has not yet been published for your specific distribution or platform, treat the system as exposed until you can confirm otherwise, rather than assuming inaction is safe.

DIESEC Perspective

We see the same pattern recur across Mittelstand environments: teams patch the application layer diligently but treat anything described as “CPU,” “firmware” or “hardware” as someone else’s problem, often because the last major CPU-class advisory (Meltdown, Spectre, Downfall) predates the current IT team’s tenure. BTR is a useful prompt to add “CPU and kernel-level speculative execution mitigations” as its own tracked line item in your patch-management program, not a footnote to the Linux kernel changelog.

Not sure whether your patch-management program actually tracks CPU-level and kernel hardening advisories separately from application patching? Contact DIESEC for a rapid patch-management and vulnerability-tracking review.

Sources: VUSec | The Hacker News
Published: 2026-10-01 | Category: Vulnerabilities & Patches | ~4 min read