Spectre BTR: a Linux root hash in 3 to 5 minutes on two Intel chips, with the kernel fix public since July

Two headlines, two leak rates, one paper

The Register reports that a new Spectre variant leaks data at 5.7 KB per second on an Intel Raptor Cove processor and 5.4 KB per second on Lion Cove. BleepingComputer, quoting the researchers, says 8 bytes per second. The ratio is about 700 to 1 (5,700 divided by 8 is 712, and 5,400 divided by 8 is 675, derived). Both figures are in the same paper. They measure different things, and only the slow one ever recovered a password hash.

The paper is Branch Target Reuse (BTR), from Vrije Universiteit Amsterdam (the VUSec group) and Scuola Superiore Sant'Anna, accepted for the ACM CCS conference in The Hague on 15 to 19 November 2026. The fast number is the authors' own estimate for the reuse step alone, on a test rig where they widened the timing window with a kernel probe. The slow number, 8 bytes per second, is the measured rate of the full exploit against a stock Ubuntu 24.04 kernel. It is the one behind the headline: the root password hash in about 3 minutes on Raptor Cove and about 5 minutes on Lion Cove.

What neither figure establishes is that this works on a server, a virtual machine, a kernel that carries the fix, or a browser. The full chain was built twice, on two Intel desktop-class processors (the paper lists an i9-14900K and an Ultra 9 285K), with one distribution's kernel, in the researchers' lab. The paper reports no attack in the wild. As of about 11:50 BST on 30 September I found no CVE, advisory or microcode update for it from Intel, AMD or Arm. The only CVEs are two Linux kernel records published on 25 July 2026, and they describe a hardening change to the BPF JIT, not a Spectre variant.

What BTR is, at the level a defender needs

Spectre v2 abuses the branch predictor: the CPU guesses where an indirect jump will go and starts running that code before it is sure. Classic attacks train the predictor with one branch to misdirect another. The authors call BTR the first practical in-place attack: the same branch is trained and misdirected, and what changes is the code at the target address. Their wording is that CPUs restore architectural code coherence after self-modification but "do not necessarily invalidate stale indirect branch prediction entries".

A just-in-time (JIT) engine compiles code into memory, frees it and reuses the space. If the predictor still remembers a target inside the old code, the CPU can speculatively jump to that address, which now sits partway into new code, at a position that was never a valid entry point. The wrong-path work is discarded, but it leaves traces in the cache that can be read. The authors call this a transient execute-after-free.

The precondition is what a defender should focus on: the attacker must already be able to run code that a JIT engine compiles. In the Linux kernel that means classic BPF (cBPF), which unprivileged programs can load through seccomp and socket filters; VUSec notes it is used by software such as Docker and Chrome. In Firefox it means JavaScript and WebAssembly from a web page. In GraalVM it means guest code such as Python. The kernel result needs local code execution. The browser case would need only a visited page, but no complete browser exploit exists.

What was measured, and on which chips

The paper tested five CPUs: Intel Raptor Cove (i9-14900K) and Lion Cove (Ultra 9 285K), AMD Zen 4 (Ryzen 9 7950X), and two Arm cores (Cortex-A76 in a Raspberry Pi 5, Cortex-X3 in a Google Tensor G3). In a bare test, stale predictor entries could be reused on all five. Beyond that the results split sharply.

What the paper shows per target and CPU. Source: Wiebing, Zhu, Biondi and Giuffrida, CCS 2026, sections 5 to 7 and tables 2 to 4.

Target	Shown	Not shown
Linux cBPF, Intel Raptor Cove and Lion Cove	Two end-to-end exploits on stock Ubuntu 24.04, kernel 6.14.0-27. 8 bytes per second and a root hash in about 3 minutes (Raptor Cove) and 5 minutes (Lion Cove). With cBPF constant blinding on: 10 bytes per second and 5 minutes on both	Server parts, older Intel generations, virtual machines, a kernel carrying the fix
Linux cBPF, AMD Zen 4	Stale entries reusable in a microbenchmark. Kernel case left out: the paper says AutoIBRS switches off indirect prediction in the Linux kernel	Any kernel leak
Linux cBPF, Arm Cortex-A76 and X3	Stale entries reusable in a microbenchmark. Arm told the authors that exploiting aligned cBPF code was too hard to justify a kernel mitigation	Any kernel leak
Firefox SpiderMonkey (JS shell)	On Intel, 6 to 7 stale entries survived a full free and reuse cycle, an estimated 36 and 62 bytes per second. On Zen 4 and both Arm cores none survived	A complete browser exploit. The authors say it needs further work
Oracle GraalVM (GraalPy sandbox)	Address reuse worked (95 to 97 per cent) and a masking step could be skipped in a test	Any leak: no stale entry survived the engine's own compilation and garbage collection, 0 bytes per second. The authors say this is not fundamental

Two things follow. "Affects Intel, AMD and Arm", as VUSec's FAQ puts it, is true of the underlying behaviour and false of the demonstrated leak: only two Intel parts leaked anything in a full chain. And the primitive tests used helpers that a real attacker would have to replace: a kernel probe to widen the timing window, a disclosure gadget placed by a kernel module, and a patched SpiderMonkey shell with a cache probe. The authors say so.

Where the 3 to 5 minutes goes: at 8 bytes per second, 300 seconds moves at most 2,400 bytes (derived), and the exploit spends much of that time on setup. By my reading of the paper's Figure 7, the two bars reach roughly 160 seconds (Raptor Cove) and 280 seconds (Lion Cove), with locating a shared memory page and preparing cache eviction the largest parts. The authors say pointer chasing means they need to leak only a small amount of data. The demonstration starts the su program itself so that the hash is in memory, and the paper says the same technique could read data from any process, giving browser cookies as an example. What leaks is a password hash, not the password: cracking it offline depends on the hash algorithm and the password, and the paper does not state the algorithm.

What the record does not establish

Open questions, what the sources say and what they leave out. Sources: the paper, the VUSec page, SecurityWeek, Intel's Product Security Center, read 30 September 2026.

Question	What the sources say	What they do not say
Does it work outside a lab?	Two exploits, two desktop Intel CPUs, one distribution kernel, helpers built by the researchers for timing and memory layout	Any use against a real system. The paper reports none and I found no report of exploitation as of 30 September
Does it beat today's default mitigations?	It bypassed the default mitigations of stock Ubuntu 24.04 kernel 6.14.0-27 before the fix existed	Any test against a kernel with the fix. The authors call IBPB on reuse the most robust mitigation but publish no result
Cloud and virtual machines?	The threat model is a local unprivileged attacker on Linux, and a guest kernel has its own cBPF	Any test in a virtual machine, container or cloud instance, or any cross-tenant leak
A new CVE from the CPU vendors?	Two kernel CVEs, 25 July 2026. AMD told SecurityWeek the paper reveals no new vulnerability in its products. Intel's advisory list has nothing after 11 August 2026	Any Intel, AMD or Arm CVE, advisory or microcode fix for BTR. Intel and Arm had not responded to SecurityWeek
Can it be detected?	Nothing	Any telemetry, signature or hunting guidance

Which defences the paper says fail, and which it says hold

The headline claim is that the exploit works despite deployed mitigations. The paper is specific about which, and about the conditions under which the stronger ones hold.

Defences named in the paper, its finding and the condition attached. Source: sections 7 and 8 and the VUSec FAQ.

Defence	Paper's finding	Condition or cost
Domain isolation such as eIBRS and Intel's branch history controls	Built to stop cross-domain training. The paper describes BTR as in-domain, and its exploits worked with the default Ubuntu mitigations enabled	The exploits self-train: one kernel dispatcher branch is used for both training and exploitation
cBPF constant blinding (the bpf_jit_harden option)	Bypassed: the second exploit runs at 10 bytes per second and takes 5 minutes	Off by default. Kernel documentation says hardening trades off performance
IBT and BTI landing pads, and FineIBT	Raise the bar but do not remove the risk. FineIBT alone is insufficient	Raptor Cove runs one instruction before the check. Lion Cove is the first race-free Intel generation the authors found. Race-free IBT plus constant blinding is much stronger but not future-proof
GraalVM sandbox address masking	A masking step could be skipped in a test	No leak was achieved
IBPB on JIT memory reuse (the kernel fix)	The authors' choice as the most robust	Tracking which cores ran the code is complex. No performance figure published
Selective retpolines, or switching off indirect prediction (IPRED_DIS)	Effective	Retpolines can affect fast paths. IPRED_DIS causes significant performance degradation
Site isolation	Confines a browser attack where fully deployed	Desktop Firefox has it. Mobile and WebKit are partial, per the paper

The Hacker News says BTR also undermines mitigations from the earlier Training Solo research by the same lead authors (CVE-2024-28956 and CVE-2025-24495), with the caveat, from Giuffrida, that the scope is limited to JIT engines. Those two CVEs were assigned by Intel and published on 13 May 2025 (NVD). BTR has no Intel CVE. Its two identifiers were assigned by the kernel project and describe the kernel's own changes, which is a different thing from a vendor naming a hardware flaw.

The label is not the control

Four labels in this story do less than they suggest.

The CVE titles. CVE-2026-64507 is titled "x86/bugs: Enable IBPB flush on BPF JIT allocation" and CVE-2026-64508 "bpf: Support for hardening against JIT spraying". Neither title says Spectre. The first record's text uses Spectre-v2 only as a condition, hardening "when Spectre-v2 mitigations are in use", and neither record names BTR or VUSec. Nothing in either connects the change to a named Spectre variant. The Linux kernel CNA reserved both on 19 July and published them on 25 July 2026 (CVE Services). Ubuntu rates them Medium, Red Hat Moderate, and SUSE rates CVE-2026-64507 moderate.

Two similarly named defences. The kernel's long-standing bpf_jit_harden option, constant blinding, is documented as hardening that "can mitigate JIT spraying". It is off by default and the paper's second exploit bypasses it. The new fix carries a title that also says hardening against JIT spraying, but it is a different mechanism: a branch predictor flush when JIT memory is reused. A dashboard that reports JIT hardening as enabled says nothing about whether the flush is running.

Fully patched. The Hacker News says the exploits work on "a fully patched Intel system with default protections enabled". The paper's wording is narrower: a stock Ubuntu 24.04 kernel, version 6.14.0-27, with that distribution's default mitigations, on a kernel that had no fix. Ubuntu's own tracker still lists 24.04 as vulnerable (below). Fully patched described the lab machine, not a machine patched against BTR.

The scores. Four sources publish four different pictures of the same two fixes. The NVD records have no score. Red Hat and SUSE score CVE-2026-64507 as an availability problem, although Red Hat's own description of it speaks of unauthorised disclosure of information. Amazon scores it as a confidentiality problem. Red Hat scores CVE-2026-64508 with every impact high. I cannot tell from the sources which reading is intended. The point is that a scanner ingesting one of these would report a different flaw from a scanner ingesting another. The same pattern, in another product family, is in our earlier briefing on two official scores for the same flaw.

Published scores for the two CVEs, read at about 11:40 BST on 30 September 2026. Red Hat's are marked draft.

Source	CVE and score	Vector as published
NVD (kernel CNA)	Both CVEs: no score, status Received	None
Red Hat	CVE-2026-64507: 5.5, Moderate	CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Red Hat	CVE-2026-64508: 7.0, Moderate	CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
SUSE	CVE-2026-64507: 5.5, moderate	CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Amazon Linux	CVE-2026-64507: 5.6, Medium	CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N

The fix was committed 90 days before the coverage

The two kernel patches were authored on 29 June 2026 (US Pacific time) by Pawan Gupta, who commits from an Intel address. Daniel Borkmann acknowledged and committed them on 1 July (UTC), and Dave Hansen, also at an Intel address, acknowledged the x86 patch. They were in Linux 7.2-rc2, tagged on 6 July (UTC). The first stable kernels carrying them, 7.1.4 and 6.18.39, are dated 18 July. 6.12.97 and 6.6.145 followed on 24 July, the CVE records on 25 July, and the oldest branch in the record, 6.1.183, on 19 August. From the first commit to the news is 90 days (1 July to 29 September, derived). From the CVE records it is 66.

The paper's account of the delay is in its ethics appendix. It says the authors told Intel, AMD, Arm and the kernel security team in April 2025; that the parties acknowledged the report and set an embargo but asked for a "full end-to-end exploit" before deploying costly mitigations; and that after the authors sent updated findings in May 2026, the kernel and Oracle deployed fixes. The paper gives no day in April, so the span from disclosure to the news is between 517 and 546 days (derived). That is the authors' account. I found no vendor account of the timeline.

Who has shipped what, at 11:40 BST on 30 September 2026

Fix status by source, read on 30 September 2026 between about 11:30 and 11:50 BST. Trackers change: Ubuntu's page was last updated on 29 September. Ubuntu and Red Hat were re-read at 11:51 BST with no change.

Who	Fixed on the record	Not fixed or not stated
Linux kernel, upstream	Mainline 7.2. Stable 7.1.4 and 6.18.39 (18 July), 6.12.97 and 6.6.145 (24 July), 6.1.183 (19 August). Later releases include it, for example 6.12.111, 6.18.54 and 7.2.8	x86 only: no Arm mitigation. Kernels before 5.18 are marked unaffected in the CVE record. No test against a fixed kernel
Debian	bookworm 6.1.187-1 (DLA-4777-1). trixie 6.12.100-1 (DSA-6405-1), current security update 6.12.111-1. bullseye not affected	Update dates not read
Ubuntu	26.04 LTS 7.0.0-31.31. 24.04 hardware-enablement 7.0 kernel 7.0.0-31.31~24.04.1. Priority Medium	24.04 standard kernel: vulnerable, work in progress. 22.04, 20.04, 18.04 and 16.04 vulnerable. 24.04 and 22.04 AWS, Azure, GCP and Oracle kernels vulnerable
Red Hat	Public 25 July, rated Moderate	RHEL 7, 8, 9 and 10: fix deferred for CVE-2026-64507, affected for CVE-2026-64508
SUSE	SLES 16.0 kernel 6.12.0-160000.38.1. Advisories published on 29 and 30 September	Overall state Pending. SLES 15 SP7: affected, packages in QA
Amazon Linux	AL2023 kernel6.12 and kernel6.18 on 17 August, kernel on 14 September. Amazon Linux 2 not affected	No unfixed entries listed
Oracle GraalVM	Native Image randomises code-cache placement by default (GR-77766). Change merged 19 August, contained in tag vm-25.4.4.1.1 (tagged commit dated 17 September)	No release note naming BTR found. Can be switched off with -H:-RandomizeRuntimeCodeCache
Mozilla Firefox	Site isolation on desktop since Firefox 95	No BTR fix. Mozilla is prioritising site isolation over IBPB, per the paper
Intel, AMD, Arm	Told the authors that mechanisms such as IBPB exist and software should deploy them, per the paper. AMD told SecurityWeek there is no new vulnerability	No BTR advisory, CVE or microcode found for Intel or AMD. Intel and Arm had not responded to SecurityWeek

Microcode and firmware. BleepingComputer's advice includes firmware updates. I found none that addresses BTR. Intel's public microcode repository lists release 20260925 (25 September, a functional update for one Meteor Lake stepping) and 20260811 (security updates for eight advisories, none titled for BTR). Intel's Product Security Center shows no advisory released after 11 August 2026. BTR is not listed on its Submitted Research page, which says the findings listed there "did not introduce new vulnerabilities in Intel products", so Intel has not said either way for BTR. AMD's product security page lists its ten most recent bulletins, the newest dated 24 September, and none concerns BTR. Arm's Spectre and Meltdown bulletin was last updated on 23 July 2025. VUSec's page says the hardware vendors "stated that mitigating mechanisms (e.g., IBPB) already exist".

Method, interests and who decided what

The paper is accepted at a peer-reviewed conference. It says its artefacts, including both exploits, are hosted on Zenodo. I did not open or link them, so I cannot say whether access is open. The name, the project page and the demonstration video are how an academic group gets a result read, and the caveats above are in the paper, not the headline. That is a description of how research travels, not a criticism of the work.

Interests are declared but unevenly. The PDF's acknowledgements say the work was supported by Intel Corporation through a project called Allocamelus, and by Dutch and EU funders. The VUSec web page names AWS, through a project called Themis, and the same public funders, and does not name Intel. The kernel fix was written by an engineer who commits from an Intel address, the vendor whose CPUs carried the demonstration, and acknowledged by another. None of that impugns the result, and it is ordinary in coordinated disclosure. It matters for one reason: the party that helped fund the work and wrote the software fix also holds the position, per the paper, that software should deploy mechanisms that already exist. Whether hardware should resynchronise predictor state when code is rewritten, which the authors say no current CPU does, is a question none of the vendor statements answers.

The vendors' positions differ, and none says the issue is unexploitable. Arm judged aligned cBPF too hard to justify a kernel mitigation. Mozilla is prioritising site isolation and Apple, per the paper, indicated similar preferences for WebKit. AMD told SecurityWeek the technique is covered by existing Spectre v2 guidance. Oracle changed how GraalVM places code. For a side channel whose vendor treats it as a feature rather than a flaw, see our earlier briefing on the Windows file notification interface.

What to do, in the order worth doing

# Running kernel version: compare with the fixed versions above and your distribution tracker
uname -r
# Is the predictor flush wired up? (may need root)
dmesg | grep -i "IBPB for BPF"
# Is constant blinding on? 0 is off (the default), 1 is unprivileged users, 2 is all users
cat /proc/sys/net/core/bpf_jit_harden

The question that exposes the gap

The fix has been public since early July under titles that never name a Spectre variant, and the chip makers have issued nothing that a scanner could match. A team waiting for an advisory about a new Spectre CVE would have waited for one that, on the record so far, has not come from them.

So the question is not whether BTR is serious. The paper shows it is real, on two chips, in a lab. The question is which of your Linux machines will run code from someone you do not trust, and what your kernel tracker says about CVE-2026-64507 for each of them today.

Key facts