1. Executive summary
Academic researchers at VUSec (Vrije Universiteit Amsterdam) and Scuola Superiore Sant'Anna have disclosed Branch Target Reuse (BTR), a new Spectre v2 variant that abuses stale indirect branch prediction entries left behind by self-modifying code in JIT engines. BTR affects Intel, AMD and Arm CPUs and has been demonstrated against the Linux kernel, Oracle GraalVM and Mozilla SpiderMonkey. Two end-to-end Linux kernel exploits leak arbitrary memory on modern Intel CPUs and bypass all enabled mitigations on a fully patched system, at roughly 8 bytes per second, enough in a demonstration to locate and extract the root password hash after it was loaded into memory. No CVE identifier, CVSS score or CISA KEV entry is available for this issue, and no exploitation in the wild has been reported. The exposure for EMEA financial services is concentrated in multi-tenant Linux estates running unprivileged cBPF consumers (Docker, Chrome, seccomp and socket filters) and in Firefox users on hosts without site isolation, where a malicious page can reach data in other tabs' address space.
2. Regulatory framing
No specific DORA/NIS2 article is directly engaged by this item. This is a coordinated vulnerability disclosure with no confirmed exploitation, no incident, and no third-party service disruption. DORA Art. 17 and Art. 19 and NIS2 Art. 23 are incident-management and reporting obligations and are not triggered by a disclosure alone. DORA Art. 28 and Art. 30 and NIS2 Art. 21(2)(d) would engage only if a client's ICT third-party arrangements require the vendor to notify and remediate this class of CPU-level flaw under contract, which is a contractual question for each client, not a fact in this item. The table below records the assessment rather than forcing a mapping.
| Article | Trigger (the fact in this item) | Practical impact |
|---|---|---|
| n/a | No incident, no confirmed exploitation, no third-party outage in the source material | No reporting or incident-management obligation is engaged by this disclosure |
3. Technical analysis & attack chain
BTR is a Spectre v2 variant. The researchers' stated insight is that modern CPUs restore architectural code coherence after self-modification but do not necessarily invalidate stale indirect branch prediction entries, meaning the branch targets. In JIT engines those stale predictions can outlive the code that created them and be reused once new code is written to the same memory. The result is what the researchers call a speculative execute-after-free primitive, which lets an attacker steer speculative execution into the new code at obsolete offsets.
Confirmed steps, as described in the source material:
- An attacker obtains the ability to run code on the target, either as an unprivileged local program or, in the browser case, as JavaScript delivered from a malicious web page.
- The attacker causes a JIT engine to write new code into a memory region previously occupied by other JIT-compiled code, leaving stale indirect branch prediction entries pointing at the old code's offsets.
- Speculative execution is hijacked into the new code at those obsolete offsets, producing the speculative execute-after-free primitive.
- The attacker uses the primitive to read memory outside the intended boundary and reconstructs the secret through pointer chasing.
Linux kernel, cBPF. The two end-to-end exploits target classic BPF. The eBPF JIT requires privilege, but cBPF remains usable by unprivileged programs, and seccomp, socket filtering and packet filtering in applications including Docker and Chrome depend on it. On modern Intel CPUs the exploit leaks arbitrary memory and bypasses all enabled mitigations, including on a fully updated system with default security settings. The researchers measured 8 bytes per second and note that careful pointer chasing means only a small amount of data must be leaked to reach the secret. In their demonstration they located and leaked the root password hash after it had been loaded into memory.
Firefox and SpiderMonkey. The attack would be launched from a malicious website running JavaScript in the victim's browser. Mozilla has not completed the rollout of site isolation, so content from other tabs may share the attacker's address space and be exposed. The proof of concept showed stale branch entries persisting in SpiderMonkey on Intel processors long enough to be reused. The researchers estimate leakage at dozens of bytes per second in this setting but state that more work is needed to build a complete browser exploit. No complete browser exploit exists.
GraalVM. BTR could let an attacker speculatively skip the memory masking that protects GraalVM's strictest sandbox mode against Spectre. The researchers reliably reused memory addresses, but GraalVM's own code compilation and garbage collection erased the stale branch entries before they could be exploited. They describe that limitation as not fundamental, which means the mitigation is incidental to current runtime behaviour rather than a designed defence.
Vendor position and fixes. The issue was reported to affected chipmakers and software developers, all of which acknowledged the research. CPU vendors stated that existing mechanisms such as the indirect branch prediction barrier (IBPB) can mitigate BTR and that fixes must be implemented in software. Linux kernel developers have added an x86 mitigation that triggers an IBPB across every CPU core whenever a cBPF program is placed in a memory region previously used by executed BPF code. Oracle has rolled out some mitigations. Mozilla's status is not given in the source material beyond the site isolation gap.
Confidence and caveats. This is a single research disclosure from one group (VUSec with Scuola Superiore Sant'Anna), reported by SecurityWeek and The Hacker News. The performance figures, the root password hash demonstration and the GraalVM findings are the researchers' own results and have not been independently reproduced in the material provided. No CVE has been assigned in the source material, no CVSS score is available, and there is no CISA KEV entry. Treat the exploitation status as proof-of-concept only.
Related but distinct research. A separate August 2026 disclosure from MIT CSAIL (Daniël Trujillo and Mengjia Yan), named INTERRUPT INJECTION, describes an unprivileged Linux program timing a hardware interrupt into the gap between a processor sanitizing its branch predictor and the kernel using it, re-poisoning the predictor after the defence has run. That work was demonstrated on an AMD Zen 2 machine running Linux 6.14 with default Spectre v2 mitigations enabled. It is a different technique against the same class of defence and is included here only because it shows the mitigation gap is being worked from more than one direction. It is not part of the BTR disclosure.
4. Mitigation & containment
There is no CPU microcode fix for BTR. The vendors' position is that IBPB can mitigate it and that remediation belongs in software, so the actions below are software and configuration controls.
P1 (within 24 hours)
- Inventory Linux hosts that run unprivileged cBPF consumers: Docker and other container runtimes, Chrome and Chromium-based browsers, and any workload using seccomp or socket and packet filters. These are the systems where the demonstrated kernel exploit applies.
- Apply the Linux kernel x86 mitigation that issues an IBPB across all CPU cores when a cBPF program is loaded into a memory region previously used by executed BPF code. Track your distribution's kernel package for the backport; the source material does not name a version, so confirm the fix is present with your vendor rather than assuming a kernel version number.
- Where the kernel fix is not yet available, restrict unprivileged cBPF use. Setting kernel.unprivileged_bpf_disabled=1 blocks unprivileged BPF program loading, but verify the impact on seccomp profiles, container runtimes and browser sandboxes before rolling it out, because those are the consumers that depend on cBPF.
- On Firefox fleets, confirm whether site isolation is enabled. Where it is not, treat cross-tab data exposure from a malicious page as reachable and prioritise the browser update channel that carries Mozilla's mitigations.
P2 (within 72 hours)
- Apply Oracle's GraalVM mitigations where GraalVM is deployed. Note that the researchers found GraalVM's own compilation and garbage collection currently erase the stale entries, so the practical risk today is lower than for the Linux kernel path, but they do not consider that limitation fundamental.
- Reduce the value of what a memory leak yields. The demonstration extracted a root password hash from memory, so rotate credentials that are held in memory on high-value Linux hosts and remove cached secrets that do not need to be resident.
- Review whether any tenant or customer workload shares a kernel with untrusted code. The kernel exploit needs only unprivileged code execution, so shared build runners, CI containers and multi-tenant batch hosts are the priority.
P3 (within 7 days)
- Add BTR to your CPU-side-channel watch list alongside the existing Spectre v2 mitigations and re-check vendor advisories for microcode or kernel updates as they land.
- For any client whose ICT third-party contracts cover CPU-level vulnerabilities, confirm with the relevant processor and OS vendors what notification and remediation commitments apply. This is a contractual review, not a technical one.
5. Indicators of compromise
No indicators of compromise available in the source material. The disclosure contains no hashes, domains, IP addresses, file paths or command lines. The observable behaviours below are the only machine-relevant signals described, and they are behavioural rather than atomic.
Behavioural indicators
| behaviour | where to observe | confidence |
|---|---|---|
| Repeated loading of cBPF programs into memory regions previously used by executed BPF code | Linux kernel audit and BPF subsystem logs; kernel tracepoints on BPF program load | Medium. Described as the trigger for the kernel mitigation; not given as a detection signature by the researchers |
| IBPB issuance across all CPU cores correlated with cBPF program placement | Kernel tracepoints and performance counters for IBPB; the mitigation itself is the observable | Medium. Follows from the described kernel fix, not from a published detection rule |
| An unprivileged process reading memory outside its expected boundary at a low, steady rate (single-digit to low-tens of bytes per second) | EDR memory-access telemetry and hardware performance counters | Low. The rate is from the researchers' demonstration; no detection guidance was published |
6. Detection
Insufficient indicators to author detection rules. The source material provides no distinctive strings, command-line flags, mutex names, scheduled-task or service names, file names or paths, registry keys, ransom-note text or hard-coded values. The only artefacts named are product and component names (cBPF, GraalVM, SpiderMonkey, IBPB), which describe the affected software rather than the threat, and a YARA or Sigma rule built from them would match reporting about the vulnerability rather than any malicious activity. Detection for BTR has to come from the behavioural signals in §5, which require kernel-level telemetry and hardware performance counters rather than file or log signatures.
7. Sources
- SecurityWeek, "New Spectre v2 Variant Exposes Intel, AMD, Arm CPUs to Data Leaks", https://www.securityweek.com/new-spectre-v2-variant-exposes-intel-amd-arm-cpus-to-data-leaks/, 2026-09-29
- The Hacker News, "New Spectre-v2 BTR Attack Leaks Linux Memory Despite Existing Defenses", https://thehackernews.com/2026/09/new-spectre-v2-btr-attack-leaks-linux.html, 2026-09
- The Hacker News, "New Interrupt Injection Attack Can Bypass Spectre v2 Defenses on Intel and AMD CPUs", https://thehackernews.com/2026/08/new-interrupt-injection-attack-can.html, 2026-08
8. Adverse Trace position
Adverse Trace assesses BTR as a research-grade proof of concept with no confirmed exploitation in the wild, no CVE, no CVSS score and no CISA KEV entry, so we are not raising it above routine patch-cycle priority for most clients. The exception is clients running multi-tenant Linux hosts where unprivileged code from different trust domains shares a kernel, and clients with large Firefox fleets that have not completed site isolation, because those are the two paths the researchers demonstrated or came close to demonstrating. The kernel exploit bypasses all enabled mitigations on a fully patched modern Intel system, which means the usual "we are patched" assurance does not cover it; the fix is a kernel backport that may not yet be in your distribution's stable channel. We will track the Linux kernel, Oracle and Mozilla advisories for named versions and for any CVE assignment, and we will re-issue this note if exploitation is reported or if a vendor publishes a version-specific fix. Clients should confirm with their OS vendor whether the cBPF IBPB mitigation is present in their current kernel, and should treat the credential-rotation step in §4 as the cheapest reduction in impact while that confirmation is pending.
Published via PulseTrace — Adverse Trace threat intelligence.