Branch Target Reuse Turns Discarded JIT Code Into a Spectre Data-Leak Primitive

Researchers have disclosed Branch Target Reuse, or BTR, a Spectre v2 variant that exploits branch predictions left behind after just-in-time compiled code has been removed from memory.

The team from VUSec at Vrije Universiteit Amsterdam and Scuola Superiore Sant’Anna demonstrated the technique against the Linux kernel. Their exploit used unprivileged classic BPF programs to extract a root password hash from a running su process.

The attack leaked eight bytes per second. Average end-to-end recovery took three minutes on Intel Raptor Cove and five minutes on Intel Lion Cove, according to research reported on September 29, 2026.

The underlying processor behavior was confirmed on every tested CPU across Intel, AMD, and Arm. However, practical exploitability varies by software environment, processor generation, and the mitigations enabled.

Stale predictions survive after JIT memory is recycled

Modern processors predict the destination of indirect branches so they can continue executing instructions without waiting for the correct target to be resolved. Spectre-class attacks manipulate or misuse this speculative behavior to access information that architectural execution should not expose.

BTR focuses on what happens when executable JIT memory is recycled.

A JIT engine can compile a program, place its machine code at a particular address, and later free that code. The same memory may then hold a different program. Although the bytes in memory have changed, the processor can retain branch-target information associated with the previous code.

An indirect branch may consequently speculate into the replacement code using an obsolete target. That target can point to an unintended or misaligned position within the new instruction sequence.

Architectural execution eventually rejects the incorrect path. Before that happens, however, speculative instructions can access sensitive data and alter the cache. An attacker can measure those cache effects and infer the data one byte at a time.

This creates what researchers characterize as a speculative execute-after-free primitive: the processor behaves as though an old control-flow relationship remains valid after the corresponding code has ceased to exist.

Linux exploit recovers a root password hash

The Linux demonstration relied on unprivileged classic BPF, or cBPF, programs. The researchers trained a branch prediction with one program, freed it, and arranged for different JIT-compiled code to occupy the same memory.

They then targeted a running su process and extracted its root password hash from memory. Reporting on the research says the exploit could leak arbitrary memory on modern Intel processors in the tested scenario, including on fully updated systems using default security settings.

The team developed two end-to-end cBPF exploits. One worked with the default configuration. The other addressed systems with BPF constant blinding enabled, a defense intended to prevent attacker-controlled constants from appearing directly in generated machine code.

For the second version, the researchers encoded attacker-controlled instructions through jump offsets. They were still able to recover the password hash within five minutes.

Obtaining a hash is not equivalent to obtaining the plaintext password. An attacker would need to crack the hash separately, potentially using offline or cloud-based computing resources. Whether that succeeds depends on the password’s strength and the hashing algorithm.

The demonstrated path also depends on the attacker being able to run unprivileged cBPF programs. More capable eBPF JIT functionality requires privileged access in the environment described by the researchers, but cBPF remains relevant to seccomp, socket filtering, and packet filtering. Applications using those facilities include Docker and Chrome.

The affected Linux kernel version ranges have not been disclosed. That prevents administrators from determining exposure solely by comparing a deployed kernel against a documented vulnerable-version list.

Two CVEs cover BPF JIT reuse and predictor flushing

The Linux changes are associated with CVE-2026-64507 and CVE-2026-64508. No CVSS scores, vectors, CWE classifications, or affected release ranges are available in the supplied NVD information.

CVE-2026-64507 concerns hardening applied when Spectre v2 mitigations are active. The kernel issues an Indirect Branch Prediction Barrier, or IBPB, when BPF JIT memory is reused, preventing stale predictions from carrying over into newly written code.

The described implementation skips that flush when the BPF dispatcher already uses a retpoline sequence. The change only applies when the BPF JIT is active and is guarded by CONFIG_BPF_JIT, allowing kernels built with CONFIG_BPF_JIT=n to compile correctly.

CVE-2026-64508 addresses how the BPF JIT allocator handles executable memory. The allocator packs small programs into larger allocations and recycles space as programs are loaded and removed. A prediction created for an old program can therefore direct speculative execution into new code placed at the same address.

The associated hardening flushes indirect branch predictors before that JIT memory is reused. Linux developers reportedly implemented an x86 mitigation that triggers IBPB across every processor core when cBPF code enters a region previously occupied by BPF code.

Fixes have been merged into the Linux kernel, but exact fixed release numbers are not known. Neither CVE has a confirmed CISA Known Exploited Vulnerabilities catalog status or remediation deadline in the available data. The demonstrated research exploit therefore should not be described as confirmed in-the-wild exploitation.

Firefox and GraalVM expose additional attack surfaces

BTR is not confined to the Linux BPF JIT. The researchers also observed relevant behavior in Firefox’s SpiderMonkey engine and Oracle GraalVM, although neither investigation produced a complete end-to-end exploit.

In SpiderMonkey, stale predictions survived the reuse of JIT code addresses on Intel processors. The researchers estimated that a completed technique might leak dozens of bytes per second, but further work would be required to turn the proof of concept into a functioning browser attack.

The potential impact depends partly on process isolation. Mozilla had not completed its site-isolation rollout, according to SecurityWeek’s account of the findings. Content from separate tabs could consequently share an address space in some circumstances, creating a possible route to cross-tab data exposure. No completed attack demonstrating that outcome has been reported.

In GraalVM, the researchers found a speculative path that could skip a sandbox check involving memory masking in the runtime’s strictest sandbox mode. They could reliably force memory-address reuse, but compilation and garbage-collection activity cleared the stale branch entries before they completed the attack.

That interference limited the experiment rather than disproving the primitive. The researchers did not consider it a fundamental barrier. Oracle has reportedly deployed some mitigations, although exact product versions and patch levels have not been disclosed.

Hardware defenses raise the cost but do not close every path

Control-flow protections such as Intel’s Indirect Branch Tracking and Arm’s Branch Target Identification can make BTR exploitation harder. They do not eliminate every technique described by the researchers.

Older Intel processors may speculatively execute instructions before the relevant control-flow check takes effect. Lion Cove was the earliest Intel generation the researchers identified as free from that particular race condition.

Even then, race-free IBT does not imply complete immunity. The researchers reportedly bypassed IBT on race-free processors when constant blinding was disabled. Combining race-free IBT with constant blinding provides a substantially stronger defense.

CPU vendors have generally pointed to existing barriers such as IBPB and argued that software should flush predictor state when executable memory changes meaning. AMD said the research did not identify a new vulnerability in its products and referred users to existing Spectre v2 guidance. Intel and Arm responses were not reported.

Administrators should prioritize kernel and firmware updates

Linux operators should install the latest kernel updates available from their distribution, particularly on systems where unprivileged cBPF functionality is accessible. Because no fixed-version matrix has been published, distribution advisories are the most practical way to identify patched packages.

Firmware and microcode updates should also be applied. They may strengthen existing speculative-execution controls, although the reported practical fix for BPF memory reuse is software-triggered IBPB.

Teams should review whether workloads require unprivileged cBPF, especially on multi-user hosts or systems running code from less-trusted tenants. Disabling functionality without understanding dependencies could disrupt seccomp or filtering workloads, so any restriction should be tested before deployment.

No attack-specific malware indicators, file hashes, domains, or network signatures have been disclosed. Detection must therefore focus on unusual local use of BPF facilities, unexpected unprivileged program loading, and suspicious activity around sensitive processes. Those signals are not unique to BTR, but they may help identify the prerequisites used in the demonstrated Linux attack.