Branch Target Reuse Spectre v2 Flaw Hits JIT Engines: Linux Kernel Fixes for CVE-2026-64507/64508

Who found it and what it targets​

The attack comes from the VUSec group at Vrije Universiteit Amsterdam in the Netherlands and Scuola Superiore Sant'Anna in Italy. According to SecurityWeek, BTR targets the just-in-time (JIT) compilers relied upon by operating system kernels, web browsers, and runtimes. The ACM CCS 2026 accepted-papers list includes the paper, "Branch Target Reuse: Practical Spectre-v2 Attacks in JIT Engines via Stale Branch Prediction Entries," by Sander Wiebing, Yuhui Zhu, Alessandro Biondi and Cristiano Giuffrida. The conference itself takes place in November.

The researchers tested three JIT environments:

• Linux kernel classic BPF (cBPF): a full end-to-end exploit
• Firefox's SpiderMonkey JavaScript engine: a partial proof of concept
• Oracle's GraalVM: a partial result that stalled before a working attack

The threat model matters here. The Hacker News reports that the attack presumes an attacker who is able to run unprivileged code in a JIT engine and is seeking to disclose sensitive data from the host environment. Nobody is hitting your server with BTR over the network without first getting code running on it.

How BTR works: the CPU forgets to forget​

Modern processors guess where an indirect branch will land so they don't have to wait for the real answer. If the guess is wrong, the CPU throws the work away. The cache still shows traces of what it touched, though, and Spectre attacks read those traces.

BTR abuses how JIT engines recycle memory. As BleepingComputer explains, when a JIT engine frees code and puts new code at the same address, the CPU may still remember an indirect branch target from the old code. The researchers put the key point this way, as quoted by The Hacker News: "while modern CPUs restore architectural code coherence after self-modification, they do not necessarily invalidate stale indirect branch prediction." In other words, the CPU makes sure it runs the new code correctly. Its branch predictor, however, can still be working from a record of the old code.

The Hacker News lays out the attack in three steps:

• The attacker lures the JIT engine into allocating a training chunk and forces the victim branch to jump to it, thereby inserting a BTB entry referencing the current entry point.
• The attacker forces a deallocation of the training chunk and an allocation of the target chunk that partially reuses the same address.
• The attacker triggers the indirect branch again, the CPU uses the now-stale branch target buffer (BTB) entry and speculatively jumps to the old training-chunk entry point.

Why is this news? Since 2018, researchers had largely assumed that self-modifying code, which is how commodity JIT engines generate code on the fly, made this kind of transient-execution attack impractical. Giuffrida told BleepingComputer that BTR shows the opposite.

Section summary: BTR doesn't inject a prediction from outside. It reuses a leftover prediction that the CPU never cleared after a JIT engine put new code at an old address.

The Linux exploit: a root hash in three to five minutes​

On Linux, the team used unprivileged classic BPF programs to train the branch predictor. They then freed the original program and loaded a different one into the same memory. The stale target sent the CPU speculatively into attacker-crafted instructions at a misaligned offset. That left a cache trace they could measure to read data one byte at a time.

They then located a running su process and pulled the root password hash out of its memory at eight bytes per second. The researchers said they tested the exploit on Intel's Raptor Cove and Lion Cove cores and leaked the hash in 3 and 5 minutes on average, respectively. The Hacker News adds that the Linux proofs of concept ran on a fully patched Intel system. That presumably means patched as of before the new fixes.

The paper describes two cBPF exploits. One runs against the default configuration. The other runs with BPF's constant blinding hardening turned on. For that version, the researchers hid their instructions in jump offsets and still got the hash in under five minutes. A hardening option that people often treat as a JIT-spraying defense did not stop it.

Keep this in proportion: a password hash is not the password itself. An attacker would still have to crack it offline. How well that works depends on the hashing scheme and the password. A modern, well-configured hash protecting a long, random root password is a very different target from a weak password.

Browsers and GraalVM: close, but no finished exploit​

The browser results deserve the most care, because this is where headlines tend to overreach.

• SpiderMonkey: SecurityWeek reports that stale branch entries persist in SpiderMonkey on Intel processors long enough to be reused. The researchers estimate that data could leak at a rate of dozens of bytes per second, but more work is needed to build a complete browser exploit.
• GraalVM: SecurityWeek says BTR could allow an attacker to speculatively skip over the memory masking that protects the runtime's strictest sandbox mode against Spectre. However, GraalVM's own code compilation and garbage collection processes erased the stale branch entries before they could be exploited. The researchers say this limitation "does not appear fundamental."

So a JavaScript-based attack from a malicious web page looks plausible, but nobody has demonstrated one yet. That applies to Firefox on Windows as much as on Linux: the concern is real, but it has not been shown to work end to end.

Intel, AMD, Arm: which CPUs are affected?​

VUSec isn't hedging. "No current CPU has a mechanism to keep the two in sync, so until vendors add one, your CPU is vulnerable." The group adds: "We confirmed this behavior on every CPU we tested, covering Intel, AMD and Arm."

That's worth taking seriously, but it has limits. The stale-prediction behavior showing up on tested chips from all three vendors doesn't mean every CPU generation is equally exploitable. The only complete root-hash exploit reported so far ran on Intel cores. The vendors also don't treat this as a new hardware emergency. SecurityWeek notes that CPU vendors pointed out that existing mechanisms, such as the indirect branch prediction barrier (IBPB), can mitigate BTR, which puts the job of applying those barriers on software.

The fixes: CVE-2026-64507 and CVE-2026-64508​

The Linux kernel CVE team's advisories show how the fix works: flush the branch predictor before JIT memory gets reused.

The kernel CVE team recommends moving to the latest stable kernel rather than cherry-picking individual commits. It also warns that the affected and fixed version lists can change as fixes get backported.

What to do now​

For admins with Linux systems, here's a practical checklist:

• Check your distribution's security tracker for CVE-2026-64507 and CVE-2026-64508. Distro kernels backport fixes, so version numbers don't always match upstream. A kernel like "6.8.0-something" may already be patched, or may not be.
• Install the patched kernel and reboot. Until the machine restarts, it's still running the old kernel.
• Confirm your running kernel with uname -r, and check the kernel's own Spectre v2 status in /sys/devices/system/cpu/vulnerabilities/spectre_v2.
• Prioritize shared systems. The attacker needs local code execution. That makes multi-user hosts, CI runners, shared build boxes and machines that run untrusted workloads the first ones to patch.
• Keep firmware and microcode current, as the researchers advise. Just don't expect a BIOS update to fix the Linux BPF JIT issue. That fix is in the kernel.
• Update Firefox and any GraalVM deployments as vendors ship hardening. No complete exploit exists for either yet, and it's easier to patch before one does.

Windows angle (my own analysis): WSL2 runs a real Linux kernel that Microsoft maintains. Developers who use it can check their kernel version with uname -r inside WSL and update it with wsl --update. I haven't seen a Microsoft statement saying which WSL kernel build includes these fixes, so treat this as a check to run, not a confirmation that you're protected.

The bigger picture​

VUSec has been finding holes in Spectre v2 defenses for years: RIDL, Branch History Injection, SLAM and last year's Training Solo all came from this group. Each time, the industry adds a barrier or a new instruction, and a few years later someone finds another way around it. BTR fits that pattern. Hardware keeps getting faster by predicting things, and software has to keep flushing those predictions at the right moments to stay safe.

BTR is not a drive-by attack that empties your desktop's secrets today. It needs local code execution, it leaks slowly, and the browser version isn't finished. For Linux fleets, the kernel fix is available, so the practical step is to install your distribution's patched kernel and reboot.

Update: Additional details (September 30, 2026)​

TechRadar reports that the researchers measured potential leakage rates of 5.7 KB/s on Intel Raptor Cove and 5.4 KB/s on Lion Cove in their proof-of-concept work. It also says Oracle has released a mitigation, alongside the Linux kernel changes tracked as CVE-2026-64507 and CVE-2026-64508.

According to TechRadar, Mozilla is prioritizing site isolation rather than a direct BTR-specific mitigation. IBPB flushing is expected to help, but carries a performance cost.