Branch Target Reuse steals the Linux root password hash in minutes

September 29, 2026. Researchers from VUSec at the Vrije Universiteit Amsterdam publish Branch Target Reuse (BTR), a new Spectre v2 variant that targets JIT engines. September 2026. Two end-to-end exploits recover the Linux root password hash in minutes from a fully patched Intel machine running default defenses. September 29, 2026. The fixes land as CVE-2026-64507 and CVE-2026-64508. Why it matters: the attack reuses branch targets that became stale after a JIT rewrote its own code — an angle that existing Spectre v2 defenses never covered.

A blind spot Spectre v2 missed

Since 2018, defense against Spectre v2 has rested on one assumption: if you fence off valid branch targets, you stop the branch predictor from speculating into attacker code. The classic mitigations — IBPB, STIBP, return barriers, and especially eIBRS on newer processors — all address indirect branches whose target remains architectural.

BTR breaks that assumption by exploiting the interplay between self-modifying code (SMC) and indirect branch prediction. The observation by researchers Sander Wiebing, Yuhui Zhu, Alessandro Biondi, and Cristiano Giuffrida fits in a single sentence: when a modern CPU runs code that modifies itself, it restores architectural coherence but does not necessarily invalidate stale entries in the branch target buffer (BTB). Inside a JIT engine, those stale targets can outlive the original code and later be reused when the code cache is repopulated. The result is a “transient execute-after-free” primitive that hijacks transient control flow into freshly generated code at now-invalid offsets.

The attack unfolds in four steps. First, the attacker lures the JIT into allocating a training chunk and makes the victim branch jump to it, planting an entry in the BTB. Next, they free that chunk and allocate a target chunk that partially reuses the same address. They trigger the indirect branch again: the CPU reuses the now-stale BTB entry and speculatively jumps to the old training-chunk entry point. Finally, that transient execution — by touching memory or running misaligned gadgets — leaves a cache-observable trace the attacker measures to reconstruct secrets.

Three JIT engines hit, one kernel that leaks

The researchers evaluated BTR against three targets: SpiderMonkey (the JIT engine inside Firefox), GraalVM, and the Linux kernel’s cBPF JIT. All three are affected, though with “markedly different exploitability characteristics and leakage rates,” according to the paper.

The kernel case is the most telling. By attacking the cBPF interpreter’s JIT, the researchers built two end-to-end exploits able to leak and then recover the root password hash within minutes. The target: a recent Intel machine, fully patched, with Spectre defenses enabled by default. In other words, an attacker with nothing more than an unprivileged user account and the ability to load a BPF program can hope to read kernel memory — the exact scenario Spectre v2 defenses were supposed to make impossible.

The blast radius extends beyond the kernel. SpiderMonkey runs untrusted JavaScript inside Firefox; if a website managed to weaponize BTR through the browser’s JIT, it would read the renderer process’s memory. Mozilla has announced no immediate mitigation: the vendor is studying IBPB-based defenses but says it is prioritizing the rollout of site isolation, which already limits what a compromised content process can reach.

The practical prerequisite narrows the immediate risk. BTR assumes an attacker who can already run unprivileged code inside a JIT engine — a script in a browser, a program on a GraalVM runtime, or a BPF program on the host — and who seeks to disclose data from the surrounding environment. That is precisely the profile of a multi-tenant or shared-host workload, not a single-user laptop. The severity is highest wherever the gap between “can run code” and “can read memory” is the security boundary you rely on.

Fixes with different geometries

The vendors’ responses are not uniform, and that is instructive. In the Linux kernel, mitigations were merged and published as CVE-2026-64507 and CVE-2026-64508; applying your distribution’s updates is the first action. GraalVM takes a different path: instead of barricading the predictor, it randomizes JIT code-cache locations, which makes the address reuse at the heart of the attack harder. Mozilla, finally, is stalling in favor of isolation rather than a costly predictor barrier.

This heterogeneity echoes a lesson from 2018: there is no universal mitigation for speculative-execution attacks. Every surface that runs untrusted code — browser, virtual machine, kernel with BPF, multi-tenant serverless — must be reasoned about separately. The kernel fix does not protect Firefox, and GraalVM’s randomization does not protect the kernel.

Verify the protection is actually active

Applying the fixes is not enough: you still need to confirm the kernel actually exposes the mitigations. The following command reads the Spectre defense status the kernel reports:

$ grep -E 'spectre_v2' /sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Enhanced IBRS; IBPB: conditional; STIBP: conditional; ...

Two caveats apply. First, the BTR mitigations shipped as CVE-2026-64507 and CVE-2026-64508 do not necessarily add a new line to this file: some distributions patch the cBPF JIT itself without changing the overall declaration. So check your exact kernel version and the presence of the fixes in your distribution’s changelog rather than trusting the status file alone.

Second, that file only covers the kernel. It says nothing about Firefox or GraalVM, which carry their own fixes — or, for Firefox, a deliberate lack of mitigation in favor of site isolation. An inventory of your untrusted-code execution surfaces, not a single grep, is the real measure of your exposure.

What BTR changes in your threat model

BTR is not the first attack of its kind in 2026. It lands roughly two months after Interrupt Injection, a technique published by Daniël Trujillo and Mengjia Yan of MIT CSAIL, which also bypassed Spectre v2 defenses to leak kernel memory on Intel and AMD systems. The pace is accelerating: two speculative-execution attacks against the kernel in a single quarter suggests the research community has found a vein — JIT engines and the mechanisms that run dynamic code inside or at the gates of kernel space.

For a CISO, three practical consequences follow. First, the boundary between “untrusted code” and “host” is porous again on the very CPUs that were supposed to seal it: a plain user able to inject BPF (or code into a JIT) can no longer be treated as someone without memory risk. Second, the kernel patch is necessary but not sufficient: you must inventory every component that executes dynamic code and check its own posture. Third, side-channel exfiltration remains a blind spot for classic detection tooling — a leak that travels through the cache produces neither a network alert nor a log entry.

Verdict

If you run multi-tenant workloads or untrusted code (browsers, VMs, serverless, a kernel loading user-supplied BPF), apply the CVE-2026-64507 and CVE-2026-64508 kernel fixes immediately, then inventory your JIT engines: the kernel patch covers neither Firefox nor GraalVM. If you operate a platform that hosts arbitrary code, start treating tenant isolation as a property to be proven, not assumed — GraalVM’s randomization shows that an unpredictability defense is cheaper than a hardware barrier, but it is only a stopgap. And if you manage a fleet of desktops or servers, return to basics: a root-hash leak in minutes only becomes critical if that hash is weak, reused, or crackable — a solid password, authentication, and rotation policy shrinks the impact of transient memory reads before they turn into a compromise.

References

• The Hacker News — New Spectre-v2 BTR Attack Leaks Linux Memory Despite Existing Defenses (September 29, 2026)
• BleepingComputer — New Spectre v2 attack variant leaks Linux root password hash in minutes (September 29, 2026)
• Phoronix — Branch Target Reuse, BTR: New Spectre V2 Attack Targeting JIT Compilers (September 29, 2026)
• VUSec — Systems and Network Security Group, Vrije Universiteit Amsterdam