Spectre v2 variant lifts a Linux root hash in three minutes flat

The 2018 assumption was wrong

Ever since the first Spectre volley in 2018, a comfortable belief had settled in: this class of transient-execution attack would never be practical against JIT engines, because the self-modifying code (SMC) that underpins dynamic code generation made the whole exercise a non-starter. Cristiano Guiffrida of VUSec reminded Bleeping Computer of exactly that on 29 September 2026: killing the assumption matters as much as the leak itself. The attack is called BTR, for Branch Target Reuse.

The mechanism fits into one uncomfortable sentence. When a JIT engine frees a chunk of compiled code and drops a new one at the same address, the processor still remembers the old indirect branch target. The predictor and the actual state of the code have drifted apart, and in that window the CPU speculatively runs the new code starting from a stale target. The new code is the one the attacker wrote.

Eight bytes a second

The researchers from VUsec (VU Amsterdam) and the Scuola Superiore Sant’Anna built the exploit end to end on Linux with plain, unprivileged cBPF programs: train the prediction, free the program, drop another one into the recycled memory. The stale target makes the processor run hand-crafted instructions at a misaligned offset, the speculative memory access leaves a measurable fingerprint in the cache, and the data comes back out one byte at a time.

Pointed at a running su process, that works out to eight bytes per second, and to this line from the paper: « We evaluated the end-to-end exploit on both Raptor Cove and Lion Cove, and leaked the password within 3 and 5 minutes on average, respectively ». The technical write-up ships two exploits against cBPF: one against the default configuration, one against constant blinding hardening — the latter smuggles the attacker’s instructions inside jump offsets and still walks away with the hash in under five minutes.

A hash is not a plaintext password. You still have to crack it offline or rent the compute, and how that goes depends on the hashing algorithm and on how good the password was. The problem has moved one step down the road, not away.

What changes when the machine isn’t only yours

On a shared server, the number to remember isn’t “three minutes” — it’s the word “unprivileged”. The demonstrated exploit starts from ordinary code, with no special rights, running on the target machine. Which is a precise description of what shared hosting sells to its customers.

The two other engines the team looked at point the same way without going all the way. In SpiderMonkey, Firefox’s JavaScript engine, the proof of concept shows stale predictions surviving code reuse, but there’s no full browser exploit. In GraalVM, the researchers found a way to speculatively jump over a sandbox check, except the engine’s own activity wiped the predictions before the attack finished. The foundation is poured; the rest is engineering hours.

The patches, and everything else

The affected vendors and chipmakers were notified, two identifiers were assigned — CVE-2026-64507 and CVE-2026-64508 — and the fixes are already merged into the Linux kernel. The advice comes down to two moves: apply your system and firmware updates, and get on the latest kernel.

On the substance, VUSec is a lot less soothing: indirect branch prediction is inseparable from how modern processors work, no existing mechanism keeps the predictor aligned with the state of the code, and the behaviour showed up on every processor tested — Intel, AMD and Arm alike. « No current CPU has a mechanism to keep the two in sync, so until vendors add one, your CPU is vulnerable. »

Eight years after Spectre, the branch predictor is still that helpful coworker who keeps a spare key to an office nobody uses any more. The kernel patch installs tonight; getting the silicon back in step is a problem for a future generation of chips.