Google Chrome EUVD-2026-65764

Exploitation requires two chained conditions: first, the attacker must have already compromised the Chrome renderer process through a separate, unspecified vulnerability - the renderer compromise is an explicit prerequisite stated in the CVE description. Second, the target must be running Google Chrome on Windows (not Linux or macOS) at a version prior to 152.0.7977.65, and must visit a crafted HTML page, satisfying the UI:R requirement in the CVSS vector. The attack vector is network (AV:N) and requires no authentication (PR:N) for page delivery, but the renderer pre-compromise condition (AC:H) represents a substantial technical barrier. Exploitation is limited to the Windows platform. Non-Windows Chrome installations are not affected. Absence of a pre-compromised renderer completely blocks this specific vulnerability from being exploited.

The CVSS 8.3 vector (AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H) accurately captures the high severity but also the non-trivial exploitation complexity. The AC:H metric is critical here: exploitation requires an attacker to have already compromised the renderer process, meaning this CVE represents the second stage of a chained attack, not a standalone exploit. In practice, a threat actor would need a separate renderer exploit (e.g., a JavaScript engine bug) to set the stage for this sandbox escape. EPSS at 0.27% (19th percentile) reinforces that exploitation is not widespread or automated at this time, which is expected given the sophistication required. No KEV listing confirms no confirmed active exploitation. The S:C and C:H/I:H/A:H metrics do signal that successful exploitation achieves full host-level code execution, bypassing Chrome's primary defense mechanism. Priority should be moderate-to-high for targeted attack scenarios (nation-state, APT), but lower for commodity threat models. No SSVC data provided; exploitation status is unconfirmed.

A threat actor first exploits a separate renderer-level vulnerability (e.g., a V8 JavaScript engine bug) via a crafted HTML page visited by a targeted user, gaining code execution within Chrome's sandboxed renderer process. With the renderer compromised, the attacker then triggers the type confusion flaw in Chrome's Windows Accessibility component, causing the browser to mishandle object types across the sandbox boundary. This achieves arbitrary code execution outside the sandbox at the privilege level of the Chrome browser process on the host Windows system. No public exploit code has been identified at time of analysis.