🚨 When the CPU Remembers What Software Forgot: Inside the Branch Target Reuse Spectre-v2 Attack

Spectre changed CPU security by showing that speculative execution can leave microarchitectural traces even when architectural execution is rolled back. The supplied research describes Branch Target Reuse (BTR) as a newer Spectre-v2-related attack primitive that focuses on stale indirect branch-prediction information surviving JIT code deallocation and memory reuse.

Researchers reportedly demonstrated the technique against Linux kernel cBPF, Mozilla SpiderMonkey and Oracle GraalVM, and evaluated hardware from Intel, AMD and Arm. The central idea is that a branch predictor may retain an old target while software has already freed the code that originally occupied that location.

Traditional exploitation often follows a path such as input → memory corruption → code execution. BTR is different because the architectural program state can remain valid while stale processor prediction state influences speculative control flow.

The supplied article therefore places BTR in the broader transient/speculative-execution family rather than treating it as a conventional memory-safety bug.

Modern CPUs use branch prediction so execution can continue before every indirect or conditional branch is fully resolved. When a prediction is wrong, architectural state can be rolled back, but speculative activity can leave traces in caches and other microarchitectural structures.

Spectre-v2 specifically concerns indirect branch speculation and branch-target prediction. The supplied research references established Linux mitigations including Retpolines, IBRS/eIBRS and IBPB.

That makes the BTR question particularly important: what happens when the predicted target relates to code that has already been freed and the underlying memory is later reused?

Just-In-Time compilation dynamically generates native machine code during execution. The supplied research identifies browsers, JavaScript engines, WebAssembly runtimes, language runtimes, virtual machines and kernel BPF JIT environments as relevant JIT contexts.

Normally this lifecycle is legitimate and important for performance. BTR focuses on prediction state that may persist beyond the lifecycle of the generated code.

The research reports that modern processors can maintain stale indirect branch-prediction entries after original JIT-generated code has been removed and the memory reused.

Architecturally, software can see the old code as deleted. The CPU's predictor may nevertheless retain information about the old branch target. When new JIT code occupies reused memory, that stale prediction can potentially influence speculative execution.

Stage 1 — Allocate Training Code: the attacker causes the JIT engine to generate a code region.

Stage 2 — Train the Branch Predictor: repeated indirect branches teach the processor a particular target.

Stage 3 — Free the Training Code: the original JIT code is deallocated and the memory becomes reusable.

Stage 4 — Reuse the Address: new JIT-generated code occupies part of the reused region while the processor may still retain the old prediction.

The supplied research examines classic BPF (cBPF) in the Linux kernel, including uses such as socket filtering, packet filtering, seccomp and container environments.

The researchers reportedly developed two end-to-end exploits against the Linux kernel. The article identifies CVE-2026-64507 and CVE-2026-64508 as the Linux security issues associated with the hardening response.

The supplied article emphasizes that the Linux fixes had already been merged before the public BTR disclosure and had been backported into supported kernel branches. Therefore, the disclosure should not be interpreted as proof that a brand-new unpatched Linux issue suddenly appeared on 29 September.

The supplied research describes BPF JIT allocations that can pack multiple small programs into larger executable allocations and reuse portions after programs are freed.

The kernel response described in the source is to flush the relevant branch-prediction state before reuse, preventing indirect jumps into newly written programs from reusing predictions associated with an older program.

Researchers also investigated Mozilla's SpiderMonkey JavaScript/WebAssembly engine. The supplied article describes a threat model involving a malicious web page executing JavaScript and reports leakage potential, while noting that the browser demonstration was more limited than the Linux end-to-end exploit.

Oracle GraalVM was also examined. The supplied research says BTR could interact with speculative protections in the GraalVM environment, but it does not report the same fully demonstrated end-to-end result as Linux cBPF.

The supplied research evaluated processors from Intel, AMD and Arm and reports observing the BTR behaviour across the evaluated CPU vendors.

That should not be expanded into a claim that every CPU from those vendors is exploitable in every configuration. The source identifies microarchitecture, branch-predictor behaviour, JIT implementation, memory reuse, available gadgets, mitigations, attacker capabilities and target environment as relevant factors.

Not automatically. The supplied research explicitly cautions against reducing BTR to 'visit a website → computer instantly compromised.'

For the Linux demonstration, the attack involves execution in a JIT environment and exploitation of the kernel's BPF JIT. For browser exploitation, additional browser-specific primitives are required.

Therefore, the supplied material supports treating BTR as a serious speculative-execution research result, not as a universal remote-code-execution vulnerability.

Modern operating systems and processors already use multiple speculative-execution mitigations. The supplied article lists Retpolines, IBRS/eIBRS, IBPB, branch-target protections, site isolation, JIT hardening and code randomisation.

Linux documents multiple Spectre-v2 mitigation modes. BTR reinforces the engineering lesson that a mitigation designed for one branch-prediction failure mode may not automatically address every related failure mode.

The security boundary therefore extends beyond application code and operating-system logic into runtime, JIT, CPU predictor and cache behaviour.

This is microarchitectural exploitation rather than ordinary malware behaviour.

Depending on the affected environment and exploitability, speculative leakage can potentially expose credentials, cryptographic material, kernel data, process information, application secrets and other memory-resident sensitive information.

The supplied research reports arbitrary memory leakage in its Linux end-to-end work.

This is very different from ransomware. The supplied research says defenders may not see a malicious executable, suspicious PowerShell, a C2 domain or a ransomware note.

SOC teams should therefore pay more attention to patch state and runtime configuration when investigating relevant environments:

The supplied article says BTR does not map neatly to a single conventional ATT&CK technique because it is fundamentally a hardware/speculative-execution attack primitive.

Broader intrusion techniques may be relevant only when supported by actual intrusion evidence. BTR itself should not be represented as a confirmed ATT&CK technique based solely on this research.

The supplied research frames BTR as a refinement of the broader speculative-execution problem: software lifecycle changes can create a mismatch with processor prediction history.

Spectre taught the industry that correct software does not automatically mean secure execution. BTR reinforces that lesson.

A program may correctly allocate memory, generate code, free memory and allocate new code, while processor prediction state still contains historical information.

The most interesting part of BTR is not simply that it is another Spectre-related issue. It is the mismatch between what software believes has disappeared and what the processor may still remember.

Patch the kernel. Update the runtime. Keep browser and JIT software current. Do not disable speculative-execution mitigations without understanding the security trade-off.

Think Before You Click. Stay Aware. Stay Secure.