Researchers have detailed a critical new **Spectre** CPU vulnerability variant, **Branch Target Reuse (BTR)**, which exploits **JIT** engines across various CPU architectures. This discovery highlights persistent challenges in securing modern processors against speculative execution attacks. ### Understanding BTR: A Temporal Spectre v2 Attack The **BTR** vulnerability leverages a critical oversight in how modern CPUs handle self-modifying code. While processors restore architectural code coherence after self-modification, they often fail to invalidate stale indirect branch prediction entries. As researchers Sander Wiebing, Yuhui Zhu, Alessandro Biondi, and Cristiano Giuffrida explain in their paper, "In JIT engines, these stale targets can outlive the original code and later be reused when the code cache is repopulated, yielding a transient execute-after-free primitive. This allows attackers to hijack transient control flow to newly generated code at obsolete offsets, bypassing software hardening or reaching misaligned gadgets." ### Impact and Proof-of-Concept Exploits **BTR** was successfully evaluated against prominent **JIT** engines, including **Mozilla Firefox**'s **SpiderMonkey**, **GraalVM**, and the **Linux kernel**'s **cBPF JIT**. All were found to be susceptible, albeit with varying exploitability and leakage rates. Demonstrating its severity, the researchers developed two end-to-end exploits against the **Linux kernel**. These exploits were capable of leaking and recovering the root password hash within minutes from a fully patched **Intel** system with default protections enabled. ### The Mechanics of Spectre and BTR **Spectre**, first disclosed in 2017, refers to a class of CPU vulnerabilities that exploit speculative execution. This performance optimization technique allows processors to predict and execute instructions ahead of time. Attackers can abuse this mechanism to trick a CPU into accessing sensitive data speculatively, then infer that data through cache timing side channels. **Spectre v2** specifically targets indirect branch prediction. It poisons the CPU's branch prediction mechanism, causing a victim program to mispredict a branch and speculatively execute attacker-controlled code or gadgets. Although the results of the misprediction are discarded, changes in the cache state can reveal what the victim's speculative execution accessed. **BTR** distinguishes itself by targeting **JIT** engines and arising from the interplay between Self-Modifying Code (**SMC**) and indirect branch prediction. "JIT engines do expose exploitable transient-execution opportunities induced by SMC for the first time," the researchers noted. ### Attack Workflow The attack assumes an unprivileged attacker capable of running code within a **JIT** engine, aiming to disclose sensitive data from the host environment. The sequence of actions unfolds as follows: * The attacker lures the **JIT** engine into allocating a training chunk and forces the victim branch to jump to it, creating a Branch Target Buffer (**BTB**) entry referencing the current entry point. * The attacker then forces a deallocation of the training chunk and an allocation of a target chunk that partially reuses the same address. * Upon triggering the indirect branch again, the CPU uses the now-stale **BTB** entry and speculatively jumps to the old training-chunk entry point. * This results in control-flow hijacking and the disclosure of secret data. "By redirecting control flow to an architecturally invalid entry point, the attacker can bypass Spectre hardening mitigations or execute misaligned instructions, ultimately disclosing secret data," the researchers explained. Crucially, **BTR** relies on the stale **BTB** entry not being invalidated or replaced after the **JIT** engine frees the training chunk, and the branch predictor selecting this stale entry. ### Undermining Existing Mitigations According to Giuffrida, **BTR** represents the "first example of a practical in-place Spectre-v2 attack – using the very same indirect branch for both training and testing." This challenges the conventional wisdom that such an approach would be difficult to execute, especially given that traditional **Spectre v2** attacks typically exploit 'spatial' target violations. **BTR** undermines existing mitigations for **Spectre v2**, including those for **Training Solo** (**CVE-2024-28956** and **CVE-2025-24495**). Giuffrida clarified that while the scope is limited to **JIT** engines, the reach is similar to other **Spectre v2** attacks due to operating system kernels running **JIT** engines like **cBPF**. "More fundamentally, BTR exposes a flaw in the way modern CPUs handle self-modifying / JITted code," Giuffrida stated. "They all have support to resync microarchitectural structures such as instruction/data caches when code gets rewritten. BTR shows that this is insufficient and that leaving indirect branch prediction state stale has significant security implications as well." ### Mitigations and Future Implications Following responsible disclosure, mitigations for **BTR** have been released and merged into the **Linux kernel** (**CVE-2026-64507** and **CVE-2026-64508**). **GraalVM** has addressed the issue by randomizing **JIT** code-cache locations, while **Mozilla** is prioritizing site isolation rather than **Indirect Branch Predictor Barrier (IBPB)**-based mitigations. The discovery of **BTR** carries three significant implications: * In-place **Spectre v2** attacks are practical in the "temporal" domain. * **JIT** engines must implement isolation mechanisms (like site isolation) or deploy specific **BTR** mitigations (e.g., **cBPF**'s **IBPB** mitigation). * Modern CPUs fail to resync all necessary microarchitectural states when code is rewritten, suggesting that other **BTR**-like vulnerabilities may emerge in the future. This disclosure follows closely on the heels of another speculative execution attack, **Interrupt Injection**, revealed by **MIT CSAIL** researchers Daniël Trujillo and Mengjia Yan, which can bypass **Spectre v2** defenses and leak arbitrary kernel memory from **Intel**- and **AMD**-based **Linux** systems.