VUSEC, the systems security group at Vrije Universiteit Amsterdam, has published Branch Target Reuse, a Spectre-v2 attack against just-in-time compilers. The paper, by Sander Wiebing, Yuhui Zhu, Alessandro Biondi and Cristiano Giuffrida, is accepted to ACM CCS 2026, and the Linux mitigations are already merged under CVE-2026-64507 and CVE-2026-64508.

The researchers describe the gap in one sentence, and it is the whole attack: modern processors restore architectural coherence after code is rewritten, but they "do not necessarily invalidate stale indirect branch prediction entries."

What that means in a JIT

A just-in-time compiler is a program that writes machine code while it runs and throws it away when it is no longer needed. The memory it used is then reused for the next piece of generated code.

When that happens, the processor is told the bytes have changed. What it is not told is that its prediction about where an indirect jump at that address goes is now meaningless. The old target is still in the branch predictor, attached to an address that now holds different code.

Speculation then does what it is designed to do: at the new jump, it follows the old target. For a brief window the machine executes a path chosen by code that no longer exists, touching memory the real path never would — which is exactly a use-after-free, except that it happens in the part of the processor nobody can see directly.

An attacker who controls what the JIT compiles controls both halves: the code that trains the prediction and the code that lands in the same place afterwards.

What they got out of it

The group analysed three JIT engines: the classic BPF compiler in the Linux kernel, Oracle's GraalVM, and SpiderMonkey, the engine in Firefox. They built two end-to-end exploits against Linux.

The headline one abuses the kernel's classic BPF JIT, a feature ordinary processes can reach, and chases pointers through kernel task structures and page tables to reach the shadow password file in memory. It runs on a fully patched Intel machine with the default mitigations enabled, and leaks at eight bytes a second. A root password hash is small; the arithmetic is minutes, not days.

Intel, AMD and Arm processors are all described as exhibiting the underlying behaviour.

What has been fixed, and what has not

The mitigations landed where the attack is practical rather than where the flaw is.

  • Linux issues an indirect branch predictor barrier across cores when a classic BPF region is reused, which is the fix behind CVE-2026-64507, with separate hardening against JIT spraying as CVE-2026-64508.
  • Oracle randomises where generated code is placed in its cache, so the attacker cannot reliably land new code on an address they trained.
  • Mozilla's answer is to prioritise site isolation, which limits what a successful leak can reach rather than preventing the reuse.

The researchers are equally clear about what did not work for them. Garbage collection in GraalVM wipes the relevant predictor entries before the attack can land. A complete browser exploit against SpiderMonkey needs more work than they did. And the hardware control-flow defences that would help, Intel's indirect branch tracking and Arm's equivalent, remain incomplete on older generations.

Why this one is worth reading even if you are patched

Eight years after the first Spectre papers, the mitigations in place are a list of specific barriers in specific places. This attack did not break any of them. It found a place where nobody had put one, because the assumption everywhere else is that rewriting code invalidates what the processor believed about it.

Any component that generates code at runtime and reuses the memory inherits the same question: does the predictor state get flushed when the code changes, and if not, who else can place code there?

What to do

  • Take the kernel updates carrying the two CVEs. On Linux, this is a kernel patch, not a configuration change.
  • Update GraalVM and Firefox through the normal channels; both vendors' changes ship in releases rather than as settings.
  • If you run multi-tenant workloads where untrusted code reaches a JIT, treat unprivileged BPF as a capability to be switched off, not a default to be tolerated.
  • Do not read a vendor statement about an existing mitigation as a statement about this attack. The exploit ran with defaults on.

What is not established

  • Whether the attack is practical from a browser. The researchers say a full SpiderMonkey exploit needs more work.
  • How far it extends across cloud hypervisors and confidential-computing boundaries, which the project page does not address.
  • Which processor generations are affected to what degree, beyond the statement that Intel, AMD and Arm all show the behaviour.
  • Whether anyone has used this outside a laboratory. There is no evidence of that, and the mitigations preceded publication.