Google Chrome EUVD-2026-50725

Exploitation requires two sequential, independent conditions: (1) The attacker must have already achieved code execution within Chrome's renderer process via a separate, unrelated vulnerability - this prerequisite is explicitly stated in the CVE description ('had compromised the renderer process') and is the primary factor that raises attack complexity to AC:H; (2) the victim user must interact with a crafted HTML page (UI:R), meaning a user must be browsing to attacker-controlled or attacker-injected content while the renderer is compromised. This vulnerability is not a standalone remote code execution primitive - it functions exclusively as the second stage of a two-vulnerability exploit chain. Exploitation is not possible without the prior renderer compromise. The CVSS PR:N reflects that this bypass itself does not require additional authentication beyond renderer-level access already obtained. Non-default configuration is not required; the Receiver component is active in all standard Chrome deployments.

Real-world risk is moderate despite the scope change (S:C) in the CVSS vector. The CVSS score of 5.8 with AC:H correctly reflects that this is a second-stage exploit requiring a prior, independent renderer compromise - attackers cannot leverage this vulnerability without first achieving renderer-level code execution through a separate flaw. EPSS at 0.22% (13th percentile) signals that exploitation attempts are not currently observed at scale, which is consistent with SSVC's 'none' exploitation status and the 'Automatable: no' designation. The impact metrics C:L/I:L/A:L indicate partial rather than full system compromise at the point of sandbox escape, though a successful sandbox escape could serve as a stepping stone to more severe OS-level access. The tagging as 'Authentication Bypass' appears to be a broad or imprecise categorization - the actual mechanism is a policy bypass (CWE-693), not an authentication control failure. No KEV listing and no public POC mean this is not a current priority for most organizations, but it warrants prompt patching given Chrome's ubiquitous deployment and the nature of sandbox escapes as high-value targets for advanced threat actors who may already possess renderer exploits.

An attacker first exploits a separate, unrelated vulnerability in Chrome's renderer - such as a type confusion or use-after-free in the V8 JavaScript engine or Blink layout engine - to achieve renderer-level code execution. With the renderer under their control, the attacker delivers a crafted HTML page that sends malformed or policy-violating IPC messages through the Receiver component, exploiting the CWE-693 policy bypass to escape Chrome's sandbox and execute code in the context of the OS-level browser process. No public POC for this specific policy bypass exists at time of analysis; exploitation requires an attacker already possessing a separate renderer exploit, making this most relevant to sophisticated threat actors operating full browser exploit chains.