Leak rate of the Linux cBPF exploit: 8 bytes per second (Source: VUSec, Branch Target Reuse project page (covered September 29, 2026))
Many security controls assume code runs in the order its author wrote it. A processor that guesses ahead does not follow that order. That gap is the lesson of a new attack from VUSec, the systems security group at VU Amsterdam. Its researchers produced two full attacks on the Linux kernel, and the chip makers say the fix belongs in software.
What the researchers found
The attack is called Branch Target Reuse, or BTR. It is a new variant of Spectre v2, a family of flaws in how processors predict what code will run next. BTR targets just-in-time (JIT) compilers. A JIT compiler converts a program into processor instructions while it runs, to gain speed. Browsers, language runtimes and the Linux kernel all rely on them.
VUSec analyzed three of them: Linux cBPF, Oracle GraalVM and SpiderMonkey, the engine in Firefox. Against Linux, the team delivered two complete attacks, from setup through to stolen data. In its demo, an exploit on a modern Intel CPU leaked the root password hash, and the researchers say it bypassed all enabled mitigations. It leaks 8 bytes per second.
That rate sounds slow. The researchers explain why it is enough. They follow pointers through kernel memory, so they read only the small amount of data needed to reach the secret.
How it works
A processor keeps a memory of where indirect jumps went before, called the branch target buffer. When code is rewritten, the CPU makes sure the new code is what actually runs. The researchers found it does not necessarily erase the old jump predictions.
A JIT engine frees a block of code and later puts new code at an overlapping address. An attacker trains a jump in the first block. After the block is freed and replaced, the CPU still follows the old prediction. It briefly runs the new code from a spot the author never intended. Data leaks through cache timing, and the wrong-path work is discarded.
This matters because some defenses work only if code is entered at its front door. GraalVM's strictest sandbox masks every memory access so guest code cannot leave its arena. With BTR, the researchers jumped past the mask and read outside the arena.
Where the risk is proven, and where it is not
The evidence differs by product. The Linux exploit is complete. The researchers also bypassed the kernel's optional hardening setting, bpf_jit_harden, which is off by default.
For Firefox, the researchers got a proof of concept working. On Intel chips they put the possible leak rate at tens of bytes a second. A full browser attack, they say, still needs more work. In GraalVM, the engine's own compilation and garbage collection wiped the predictions before they could be used. The researchers call that limit not fundamental.
The attack assumes an attacker can already run unprivileged code inside the engine. The researchers say cBPF stays open to unprivileged programs. It is used in seccomp filters and packet filtering, in software such as Docker and Chrome.
Who has to act
The researchers say every CPU they tested was affected, across Intel, AMD and Arm. The hardware vendors replied that mitigations such as IBPB, a barrier that clears branch predictions, already exist. They said BTR fixes should be deployed in software.
That is the decision-making point. The chip vendors say the fix belongs in software. VUSec notes that no current CPU keeps predictions in sync with rewritten code, until vendors add a way to do so. For now, each layer of software must protect itself, and each has answered differently.
The Linux kernel now flushes the branch predictor on every core when a cBPF program reuses memory that held earlier compiled code. The fixes carry CVE-2026-64507 and CVE-2026-64508. Oracle's GraalVM randomizes where JIT code is stored. Mozilla considered IBPB but is prioritizing the completion of site isolation, which keeps sites in separate processes.
Questions to put to your team
Ask which Linux hosts run kernels that include the fixes for CVE-2026-64507 and CVE-2026-64508. Ask which systems run code you do not fully control, such as plugins, customer scripts or shared container hosts. Those are the cases the attack model covers.
Ask whether any workloads use GraalVM sandboxes, and confirm your version has Oracle's patch. Ask how Firefox is deployed and what your browser policy assumes about tab isolation.
The researchers add that Indirect Branch Tracking and Branch Target Identification raise the bar without removing the risk. Do not treat them as a substitute for patching.
The lesson is simple. When a chip flaw is left to software, patching becomes a task for every team that runs that software.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: VUSec.
