Vulnerabilities
Branch Target Reuse: Spectre v2 through JIT code
BTR reuses stale branch predictions in JIT engines to leak a Linux root password hash in minutes. Fixed kernels, the sysctl that won't help, and checks.
Researchers from the VUSec group at Vrije Universiteit Amsterdam and Scuola Superiore Sant'Anna in Italy have published Branch Target Reuse (BTR), a new variant of Spectre v2, the class of CPU attacks that trick the processor's branch predictor into running code speculatively where it should not. BTR targets just-in-time (JIT) compilers: the Linux kernel's classic BPF (cBPF) JIT, Mozilla's SpiderMonkey JavaScript engine in Firefox, and Oracle's GraalVM. Every Intel, AMD and Arm processor the team evaluated was affected. Their end-to-end exploit uses the kernel's cBPF JIT to pull the root password hash out of a running su process on a fully patched Intel machine, default protections on, in three to five minutes.
The Linux side has two CVEs, CVE-2026-64507 and CVE-2026-64508, and the fixes went into the kernel in July and have been backported to the stable branches. The attacker needs to run code on the machine, so the hosts that matter most are the ones where people or workloads you do not fully trust share a kernel: shared shell servers, CI runners, and container nodes. If one of those is still on a kernel from before late July, it is the one to update first.
How it works
A modern CPU guesses where an indirect branch (a jump whose destination is only known at run time) will go, using a table of past destinations called the branch target buffer. It runs ahead at the guessed address and discards the work if the guess was wrong; Spectre v2 poisons the guess so the discarded work touches secret data and leaves a measurable trace in the cache.
JIT engines write machine code into memory at run time, free it when it is no longer needed and reuse the same addresses for new code. The CPU keeps the code itself consistent after such a rewrite. What it does not do, on any of the processors tested, is throw away branch predictions that pointed into the old code. The researchers call this a speculative execute-after-free: a prediction outlives its code and sends the CPU into the new code at an offset that only made sense for the old one, often mid-instruction. Those misaligned bytes decode into instruction sequences the JIT never meant to emit, which an attacker can shape into gadgets.
The Linux exploit relies on one detail of the kernel: any ordinary process can attach a cBPF socket filter, and the kernel compiles it to native code with its JIT. So an unprivileged user can load small filters, free them and load new ones, steering which code lands at which address until the stale prediction points where they want. Against Intel Raptor Cove and Lion Cove cores the team leaked kernel memory at about eight bytes per second, enough to recover the root password hash in three to five minutes.
The same stale entries were shown to persist in SpiderMonkey on Intel CPUs, and SecurityWeek reports that an attack from a malicious web page looks feasible, but the researchers have not built a complete browser exploit.
What attackers are doing
There are no reports of BTR being used in the wild. The kernel CVEs were published on July 25, 2026, two months before the paper, so distributions have had time to ship fixed kernels. The practical risk sits on systems where an untrusted user or workload can run code and the kernel has not been updated since.
What the vendors changed
CPU vendors told the researchers that the existing Indirect Branch Prediction Barrier (IBPB), an instruction that flushes the branch predictor's learned targets, can stop BTR, and that the fix belongs in software. Each JIT engine chose a different approach.
In Linux, CVE-2026-64508 adds a generic hook to flush indirect branch predictors before JIT memory is reused. CVE-2026-64507 wires it up on x86 so the kernel issues an IBPB across every CPU core when a cBPF program is placed in memory that earlier BPF code used. The flush applies when Spectre v2 mitigations are active, and is skipped where the BPF dispatcher already uses retpoline sequences. To limit the cost, it covers only cBPF, the unprivileged path, and the allocator now steers cBPF toward memory that has not held code since the last flush.
Oracle randomizes where GraalVM places its JIT code-cache regions, which makes it hard for an attacker to land new code on a trained address. Mozilla considered IBPB-based mitigations and is instead prioritising finishing and deploying site isolation, which keeps each site in its own process.
What to do
1. Update the kernel, shared hosts first
The upstream fixes are in 6.1.183, 6.6.145, 6.12.97, 6.18.39 and 7.1.4. Kernels from 5.18 onward are listed as affected. Distribution kernels carry their own version numbers, so search the package changelog for the CVE IDs rather than comparing uname -r:
- Debian and Ubuntu:
apt changelog linux-image-$(uname -r) | grep -E 'CVE-2026-6450[78]' - RHEL, Rocky, Alma and Amazon Linux:
rpm -q --changelog kernel | grep -E 'CVE-2026-6450[78]'
Order the rollout by who can run code on the box: multi-tenant shell servers, self-hosted CI runners and container nodes running other teams' or customers' workloads come before single-purpose servers.
2. If you cannot reboot yet
kernel.unprivileged_bpf_disabled will not help here. It only controls whether unprivileged users can call bpf() to load eBPF programs; classic socket filters attached with setsockopt(SO_ATTACH_FILTER) do not go through it. Keep it at 1 or 2 anyway, since Intel recommends disabling unprivileged eBPF against the related Branch History Injection attacks.
The stopgap that removes the cBPF JIT path is sysctl -w net.core.bpf_jit_enable=0, which makes the kernel interpret BPF instead of compiling it. Many distribution kernels are built with CONFIG_BPF_JIT_ALWAYS_ON, and on those the setting is locked at 1 and the write fails.
3. Confirm Spectre v2 mitigations are on
The kernel fix only activates when Spectre v2 mitigations are enabled. Run cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 and make sure it does not say Vulnerable, and check /proc/cmdline for mitigations=off or spectre_v2=off, which some teams set on build hosts for speed.
4. Check for exposure and rotate
A side channel leaves no log entry, so there is no reliable indicator of a past BTR attack. Check exposure instead: which unpatched hosts gave shell or container access to people outside the admin team. If you want a signal going forward, an audit rule such as -a always,exit -F arch=b64 -S setsockopt -F a2=26 records socket filter attachments (26 is SO_ATTACH_FILTER on x86). It is noisy, because tcpdump and many system services attach filters, so baseline it before alerting on it.
For hosts where an untrusted user had access before patching, treat the root password hash as exposed. Change the root password to a long random value, or lock it with passwd -l root if administrators use sudo, and make sure /etc/shadow uses a slow hash such as yescrypt or SHA-512 crypt so a leaked hash is expensive to crack.
The wider lesson
Recent Spectre-class fixes, BTR included, ship as changes to the software that creates the exposure, here the BPF JIT allocator, and they often switch on only when the base Spectre mitigations are enabled. A host booted with mitigations=off for speed misses each of these fixes as it lands, with nothing in the update log to say so. Keep an inventory of hosts that run untrusted code, record which of them have mitigations disabled, and review that list whenever a new CPU side channel is published.
Our safeguarding and hardening work covers kernel settings, sysctls and patch cadence on Linux fleets, and our cloud and Kubernetes security reviews look at which workloads share a node and a kernel. Open the chat and Yaali, our AI agent, will pass your question to an engineer.
Sources: The Hacker News, SecurityWeek, BleepingComputer, Phoronix, Hardware Busters, OSV CVE-2026-64507, OSV CVE-2026-64508, OpenCVE CVE-2026-64507, cBPF JIT spray hardening patch series, Intel guidance on Branch History Injection.