Branch Target Reuse: how the new Spectre v2 variant hits JIT, the Linux kernel and sandboxes

Researchers have presented a new variant of the Spectre v2 class of attacks called Branch Target Reuse (BTR), which affects Intel, AMD and Arm processors and allows secrets to be extracted from memory via JIT engines and the Linux kernel, up to and including the root password hash, in a matter of minutes. Vulnerable are any environments where untrusted code can run JIT or use filters/programs in the kernel (for example, cBPF), while protection requires updating the Linux kernel (CVE-2026-64507, CVE-2026-64508), configuring hardware branch predictor barriers, and revisiting JIT usage policies in isolated environments.

Technical details of the Branch Target Reuse attack

The BTR attack is described by researchers from VUSec and Scuola Superiore Sant’Anna and analyzed in detail on the project page Branch Target Reuse. Essentially, it is an evolution of Spectre v2: the attacker not only poisons the indirect branch predictor, but also leverages the fact that the predictor’s state outlives the corresponding machine code in memory.

The key mechanism is:

• indirect branches are recorded in the branch predictor together with their branch targets;
• the JIT or the kernel frees the page containing the code and then uses the same memory address for new code;
• the predictor continues to store the “old” branch target that belongs to the code that has already been freed;
• when executing the new code, the processor can speculatively jump to the stale target and execute a fragment useful to the attacker.

The authors describe this as a “speculative execute-after-free” for code: even after memory is freed and reused, the branch continues to speculatively target the old fragment until the predictor is cleared.

Exploitation via cBPF in the Linux kernel

As a practical scenario, the researchers demonstrated exploitation via JIT compilation of classic BPF (cBPF) in the Linux kernel. The JIT engine in the kernel generates machine code for filters in memory and can then free and reuse the same pages — ideal conditions for BTR.

Two proof-of-concept exploits for Linux were developed:

• for the default kernel configuration;
• for a configuration with constant blinding enabled (which makes direct control of constants in the generated code more difficult).

The first variant exploits a simple sequence:

1. the attacker loads an initial cBPF program whose task is to “train” the branch predictor on a specific pattern of indirect branches;
2. this program is then removed, freeing the memory containing its code;
3. a second cBPF program, designed to leak data via a side channel, is placed in the same address range;
4. the branch predictor still retains the indirect branch target from the first program, and the CPU speculatively executes the fragment that is useful to the attacker in the second program.

This is enough to read arbitrary memory at a rate of about 8 bytes per second. In their demonstration, the researchers located the su process and extracted the root password hash from its memory, spending only a few minutes on the attack.

In the second exploit variant, on a system with constant blinding enabled, the researchers encoded attacker-controlled instructions into branch offsets. Despite the added complexity, the root password hash could still be extracted in under five minutes. On processors of the Raptor Cove and Lion Cove architectures, the average attack time was about three and five minutes, respectively.

The related Linux kernel issues were assigned identifiers CVE-2026-64507 and CVE-2026-64508. Descriptions of the vulnerabilities are available both in the Linux mailing list CVE-2026-64507 and CVE-2026-64508, and in the NVD database: CVE-2026-64507 in NVD, CVE-2026-64508 in NVD.

Attempts to attack SpiderMonkey and GraalVM

BTR was also tested against higher-level JIT engines:

• SpiderMonkey (the JavaScript engine in Firefox) — stale predictions did indeed “survive” memory reuse, which confirms the fundamental nature of the effect. However, a full browser exploit could not be created due to additional protection mechanisms and the complex internal dynamics of the browser.
• Oracle GraalVM — the researchers managed to speculatively bypass the memory address masking mechanism that is specifically designed to protect the sandbox from Spectre-like attacks. Nevertheless, they did not reach a working attack: background activity in GraalVM was flushing predictor entries too quickly.

The key conclusion: the Branch Target Reuse effect is reproducible on all tested Intel, AMD and Arm processors and appears in various types of JIT, even when their own internal protections are fairly aggressive.

The hardware barrier Indirect Branch Predictor Barrier (IBPB), described in Intel’s guide Software Security Guidance: Indirect Branch Predictor Barrier, makes exploiting BTR more difficult, but at the cost of a noticeable performance hit.

Threat context: where BTR fits in the Spectre family

BTR is not a new “hole” in a specific product but a demonstration of a systemic limitation of modern microarchitectures. Spectre v2 techniques have for several years been considered “closed” by vendors thanks to a combination of barriers, retpoline and compiler modifications. BTR shows that even with these measures, the branch predictor remains poorly synchronized with the lifecycle of code in memory.

Important implications:

• any platform where untrusted code can trigger JIT code generation and unloading is potentially affected: browsers, Java virtual machines, .NET, GraalVM, smart contract engines, regular expression engines in databases, and so on;
• the OS kernel is no exception: JIT in packet filtering subsystems (cBPF, eBPF) becomes yet another channel for leaking inter-process secrets;
• the classic “process–address space” boundaries are weakened: a low-privileged attacker can read data from a higher-privileged process or from the kernel, bypassing direct memory access errors.

The study does not provide examples of in-the-wild exploitation and does not link BTR to specific threat actors or operations, but the history of Spectre and Meltdown shows that as techniques are simplified and optimized, such attacks gradually enter the arsenal of advanced groups.

Impact assessment for organizations and infrastructure

BTR poses the highest risk in scenarios with shared resources and complex isolation:

• general-purpose servers and virtualization environments — especially where client containers or virtual machines can load their own filters or programs into kernel BPF subsystems;
• developer workstations and systems with intensive use of GraalVM, JVM and other heavy JIT engines — an increased likelihood of local abuse on a single machine;
• enterprise browsers — with widespread Firefox use, the completeness of site isolation mode, which reduces the value of cross-site side channels, becomes important;
• systems holding highly sensitive secrets in memory (encryption keys, access tokens, administrative passwords) — even a slow leak channel of a few bytes per second is dangerous.

If no action is taken, possible consequences include:

• extraction of privileged account password hashes and subsequent offline password cracking;
• theft of cryptographic keys, access tokens and other long-lived secrets from application or service processes;
• subtle weakening of “low-privileged code vs. high-privileged data” trust models, including within sandboxes and containers;
• regulatory risks if the leak affects data subject to industry or governmental requirements.

Practical security recommendations

1. Updating the Linux kernel

The issues described in CVE-2026-64507 and CVE-2026-64508 have already been fixed in the Linux kernel. Recommended steps:

• make sure your distribution has included patches for these CVEs;
• check for entries about these vulnerabilities in your vendor’s advisories and in NVD: CVE-2026-64507, CVE-2026-64508;
• prioritize updating servers where BPF subsystems are available to unprivileged users.

Until you can update, it makes sense to:

• restrict the right to load BPF programs to administrative accounts only;
• assess the possibility of temporarily disabling JIT for cBPF/eBPF in highly sensitive environments, if acceptable for the workloads.

2. Using hardware predictor barriers

In high-risk segments (servers with multiple levels of trust, systems processing classified or otherwise sensitive data), consider enabling mechanisms such as IBPB. Intel’s IBPB guidance is available at Indirect Branch Predictor Barrier.

A practical approach:

• enable IBPB only for processes from different trust domains (for example, when switching from an untrusted client to a process handling sectoral or government data);
• test performance impact under typical workloads before enabling it widely.

3. Managing JIT and isolation in user space

• for Firefox browsers, ensure the use of the latest versions with fully implemented site isolation, which reduces the value of potential side channels between tabs;
• in environments with GraalVM and other Java virtual machines, install Oracle updates and follow their recommendations for defending against Spectre-like attacks;
• reconsider JIT enablement policies in scenarios where it can be disabled (for example, specialized server instances that do not require maximum script performance).

4. Monitoring and operational measures

Although side-channel attacks are difficult to detect directly, you can monitor supporting indicators:

• unusual patterns of loading and unloading kernel BPF programs, especially by unprivileged users;
• abnormal use of privilege-escalation utilities (such as su) on application servers;
• generation and frequent updating of large numbers of JIT programs in untrusted contexts.

Strategically, BTR is a reason to strengthen segmentation: the most critical secrets are better kept on systems where untrusted code (including client containers and JIT-enabled runtimes) is not executed at all.

BTR demonstrates that the Spectre v2 class remains alive even after several waves of mitigations, and that the branch predictors of modern processors fundamentally cannot keep up with the dynamics of JIT and the kernel. In practice, what matters now is to update the Linux kernel to versions with fixes for CVE-2026-64507 and CVE-2026-64508, where possible enable hardware predictor barriers for critical nodes, limit the use of JIT and BPF in untrusted contexts, and reassess isolation architecture wherever different trust domains coexist on the same physical hardware.