New Spectre-v2 BTR Attack Leaks Linux Memory Despite Existing Defenses
- ID
- 29935
- Status
- summarized
- Published
- 30 Sep 2026, 1:20 AM
- Fetched
- 30 Sep 2026, 4:45 PM
- Provider
- The Hacker News
- Category
- security
- Original URL
- https://thehackernews.com/2026/09/new-spectre-v2-btr-attack-leaks-linux.html
- Source URL
- https://feeds.feedburner.com/TheHackersNews
Summary
- Score
- 6.0
- Created
- 30 Sep 2026, 4:46 PM
- Tags
- Audience
- developerssaas_startup_founders
What happened
Researchers from VUSec and Scuola Superiore Sant'Anna disclosed a new Spectre-v2 variant called Branch Target Reuse (BTR), which exploits stale indirect branch prediction entries that survive JIT code cache rewrites, creating a transient execute-after-free primitive. They confirmed it affects SpiderMonkey (Firefox's JIT), GraalVM, and the Linux kernel's cBPF JIT, with different exploitability and leakage rates across the three. Two end-to-end Linux kernel proof-of-concept exploits recovered the root password hash within minutes on a fully patched Intel system with default protections enabled. The text names no CVE, no vendor patch, and no mitigation.
Why it matters
There is no patch or CVE in this disclosure, so the only decisions available to you right now are posture ones: if you run multi-tenant Linux hosts, shared CI runners, or container platforms where untrusted code and your secrets coexist on the same CPU, this is a same-machine leak path that default protections did not stop in the researchers' test. The kernel cBPF JIT can be turned off (net.core.bpf_jit_enable=0) as a blunt lever, but the same stale-branch-target class also hits browser and JVM-style JITs you can't disable for your users, so watch for vendor guidance rather than assuming your current hardening covers it.
Discussion angle
GraalVM and the Linux cBPF JIT are both on the affected list, so ask the room: which of your production workloads actually run untrusted code on a CPU shared with secrets, and would disabling the BPF JIT or isolating tenants by host be cheaper than waiting for microcode or kernel mitigations?