OOBTypeConfusionLogicError 15 CVEs 15 mapped ⚠️ 2 exploited in the wild CWE-125CWE-787CWE-843 2025-01 → 2026-09

Turboshaft’s load/store/alias elimination and its typer optimize by proving a memory location or value is unchanged, or by narrowing a value’s range. When that reasoning is unsound it elides an initializing store or bounds check, reuses a stale value, or claims a type narrower than the operation can produce. For a defender this yields OOB access or type confusion from compiler state that no longer matches runtime reality.

Invariant
Elimination may only reuse or remove a memory operation or value when nothing between definition and use can change the underlying object, map, elements kind, or allocation, and the typer must never assign a value a range narrower than the operation’s true output.

Mechanism

Members trust invalidation that is too narrow: a Call or migrating CheckMaps leaves recorded maps or load-elimination state stale (CVE-2026-10910, CVE-2026-79236, CVE-2026-87536), initializing stores are emitted as plain stores and removed (CVE-2026-15132), loop-allocated objects are treated as loop-invariant (CVE-2026-84326), and stale phi replacements or fixpoints survive (CVE-2026-7899, CVE-2026-9973, CVE-2025-0291, CVE-2025-0611). The inlined Array.sort trusts a re-entrant comparefn not to mutate elements kind or backing store (CVE-2026-10936, CVE-2026-85046), and additive-safe-integer feedback/typing narrows arithmetic ranges unsoundly (CVE-2026-11075, CVE-2026-76043).

Fix shape

Fixes widen invalidation (WipeAllMaps, InvalidateAllNonAliasing after calls), mark initializing stores, reset stale replacements to Invalid, add COW/ changed-elements guards or bail out of inlining, and flip killswitch defaults for unsound feedback.

CVEs in this pattern

1 component · V8
CVEWhatComponentVendorSeverityMonth
CVE-2026-84326 UninitializedMemory in V8 V8 chrome High 2026-09 🔧
CVE-2026-85046 TypeConfusion in V8 V8 chrome High 2026-09 ⚠️ 🔧
CVE-2026-87536 UAF in V8 V8 chrome High 2026-09 🔧
CVE-2026-102299 TypeConfusion in V8 V8 chrome High 2026-09 🔧
CVE-2026-76043 LogicError in V8 V8 chrome High 2026-08 🔧
CVE-2026-79236 TypeConfusion in V8 V8 chrome High 2026-08 🔧
CVE-2026-15132 UninitializedMemory in V8 V8 chrome High 2026-07 🔧
CVE-2026-10910 TypeConfusion in V8 V8 chrome High 2026-06 🔧
CVE-2026-10936 TypeConfusion in V8 V8 chrome High 2026-06 🔧
CVE-2026-11075 OOB in V8 V8 chrome Medium 2026-06 🔧
CVE-2026-7899 OOB in V8 V8 chrome High 2026-05 🔧
CVE-2026-9973 OOB in V8 V8 chrome High 2026-05 🔧
CVE-2025-5419 OOB in V8 V8 chrome High 2025-06 ⚠️ 🔧
CVE-2025-0291 TypeConfusion in V8 V8 chrome High 2025-01 🔧
CVE-2025-0611 LogicError in V8 V8 chrome High 2025-01 🔧

Hunt for siblings

Auditors and commit scanners look for Turboshaft load/store/alias elimination that invalidates only a subset of maps or memory after a call, CheckMaps, or loop allocation, and for typer/feedback ranges (AdditiveSafeInteger) that intersect to a type narrower than the operation guarantees.

Mitigations that would catch this class

  • After any call or migrating map check, invalidate all recorded maps and non-aliasing load-elimination state rather than a narrow subset.
  • Emit array-initializing stores as initializing/transitioning so they are never eliminated, and treat each loop iteration’s allocation as distinct.
  • Guard specialized inlined array operations against re-entrant elements-kind or backing-store changes, and keep unsound range feedback behind a conservative default.