Google Chrome EUVD-2026-65820

Two sequential conditions must both be satisfied: first, the attacker must have already achieved code execution inside Chrome's sandboxed renderer process on Windows via a separate, independent vulnerability not described in this CVE; second, the target must be running Google Chrome on Windows at a version prior to 152.0.7977.65. The victim must actively navigate to or load a crafted HTML page (UI:R), so drive-by exploitation is constrained by user interaction - silent background exploitation is not possible. The vulnerability is Windows-only per the CVE description; Chrome on other operating systems is not affected. The high attack complexity (AC:H in the CVSS vector) quantifies the renderer-compromise prerequisite - this bug is not independently exploitable from a clean browser state and cannot be triggered without first clearing that prerequisite. Limiting factors therefore include: the mandatory two-stage chain requiring a separate renderer exploit, required user interaction, and explicit Windows platform scope.

The NVD-assigned CVSS 3.1 score of 8.3 (High) with vector AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H accurately reflects the chained nature of exploitation: high attack complexity captures the renderer-compromise prerequisite, scope change reflects the sandbox escape, and full C/I/A confidentiality-integrity-availability impact reflects the consequence of executing outside the sandbox. EPSS at 0.35% (28th percentile) is low, indicating no observed broad exploitation trend at time of analysis. SSVC independently rates exploitation as none and automatable as no, consistent with the EPSS signal and the two-stage chain requirement. SSVC's technical impact rating of total is the one discordant note - it underscores that successful exploitation, if achieved, is fully compromising. The absence of a CISA KEV entry confirms no confirmed in-the-wild exploitation at publication time. Taken together, these signals indicate a high-severity vulnerability with currently low real-world exploitation pressure; the primary risk driver is that sandbox-escape primitives are highly prized in browser exploit markets and chaining renderer bugs with sandbox escapes is an established adversary technique - even a mid-sized organization's IT team should treat this as an urgent patch rather than a deferred update.

An attacker hosts a crafted HTML page that first exploits a separate renderer vulnerability to gain code execution inside Chrome's sandboxed renderer process on a Windows host. From that sandboxed foothold, the attacker triggers the out-of-bounds write in the Crashpad component by causing a crash-related code path to process attacker-controlled data, overwriting adjacent memory to gain control of execution flow outside the sandbox and achieving arbitrary code execution at Chrome process privilege. No public exploit code has been identified at time of analysis, but two-stage renderer-plus-sandbox-escape chains are a well-documented browser attack pattern used by advanced threat actors.