Google Chrome EUVD-2026-35231

Exploitation requires three concrete prerequisites that must all hold: (1) the target must be running Google Chrome on Windows at a version prior to 149.0.7827.103 - Aura on other platforms and other browser engines are out of scope of this CVE; (2) the attacker must already have arbitrary code execution inside Chrome's sandboxed renderer process, typically obtained by chaining a separate renderer-side vulnerability such as a V8 or Blink bug, since the Aura code path is not reachable from untrusted web content directly; and (3) the victim must perform user interaction by navigating to or rendering a crafted HTML page (UI:R in the CVSS vector). Limiting factors include the High attack complexity (AC:H) reflecting the need to win a race or massage the heap reliably across Windows allocator behavior, and the requirement that site isolation and the standard Chrome sandbox be in their default-enabled state for this bug to even be a relevant escape target rather than direct host access.

This is a chained-exploit primitive rather than a standalone RCE: the CVSS 8.3 score reflects AV:N/AC:H/PR:N/UI:R/S:C with high impact on confidentiality, integrity, and availability, but the High attack complexity and the description's explicit prerequisite of a 'compromised renderer process' mean an attacker must already hold a renderer RCE (typically a separate V8 or Blink bug) before this issue becomes useful. The scope change (S:C) and Chromium's internal 'Critical' rating reflect that successful exploitation breaks the security boundary between the sandbox and the host OS, which is exactly the capability nation-state and commercial spyware actors pair with renderer bugs to achieve full-chain browser exploitation on Windows. No EPSS score was supplied in the input and the CVE is not in CISA KEV, so exploitation appears theoretical at this time; however, sandbox-escape UAFs in Aura have historically appeared in in-the-wild Chrome exploit chains, so the practical risk for high-value targets is meaningfully higher than the 8.3 numeric score implies. Confirmed signals: vendor patch and Chromium severity. Missing signals: EPSS, KEV status, and any public POC - absence should not be read as safety.

An attacker first lures a target to a malicious or compromised website that delivers a renderer-process exploit (for example, a V8 type confusion) to gain code execution inside the sandboxed renderer. From there the attacker's payload sends crafted IPC messages or DOM/UI events that drive the browser-process Aura code into the use-after-free state, then sprays the freed allocation to gain control of the dangling pointer's referent, achieving code execution in the unsandboxed browser process and full escape onto the Windows host. No public exploit is identified at time of analysis, but this is the canonical pattern for Chrome full-chain exploitation observed historically.