Preparser or protocol parser disagrees with authoritative parse
Two parsers over the same input apply different rules, so a fast/pre pass reaches a different conclusion than the authoritative pass. The resulting state desynchronization yields strict-mode escape, swapped reparse ids, smuggled headers, or non-standard token acceptance. The core defect is a parser differential, not a memory error at the parse site itself.
Mechanism
arguments evades strict-mode detection and desyncs from the full parser (CVE-2025-8010). Static and instance class-member initializers share indistinguishable FunctionKinds so their reparse info_ids get swapped (CVE-2026-0899). An allowlist check parses CRLF-only while the request builder normalizes LF to CRLF, smuggling hidden headers (CVE-2026-87589). The crdtp JSON parser accepts comments that JSON.parse rejects, diverging from every compliant consumer (CVE-2026-95274). The state gap becomes type confusion, OOB, or a security-check bypass.Fix shape
CVEs in this pattern
3 components · V8, SiteIsolation, DevTools| CVE | What | Component | Vendor | Severity | Month | |
|---|---|---|---|---|---|---|
| CVE-2026-87589 | AuthorizationError in SiteIsolatio | SiteIsolation | chrome | Medium | 2026-09 | 🔧 |
| CVE-2026-95274 | LogicError in DevTools | DevTools | chrome | High | 2026-09 | 🔧 |
| CVE-2026-0899 | OOB in V8 | V8 | chrome | High | 2026-01 | 🔧 |
| CVE-2025-8010 | TypeConfusion in V8 | V8 | chrome | High | 2025-07 | 🔧 |
Hunt for siblings
Auditor/fuzzer signal: differential fuzzing that feeds identical input to the preparser vs full parser (or allowlist check vs request builder) and flags any divergence in strict-mode, kinds, header set, or accepted tokens.
Mitigations that would catch this class
- Delete lenient special cases so the pre/protocol parser matches the authoritative grammar exactly
- Encode disambiguating state (distinct kinds, explicit ids) so reparse cannot swap or downgrade
- Use one shared line-splitting and normalization routine at both check time and apply time