Google Chrome EUVD-2026-65780

Two specific prerequisites must both be satisfied: (1) the attacker must have already compromised the Chrome renderer process via a separate vulnerability - this is an explicit prerequisite stated in the CVE description and is not a default or trivially achieved state; and (2) the victim user must be socially engineered into visiting a crafted HTML page, confirming the UI:R (user interaction required) metric. The CVSS PR:N metric indicates no authentication to Chrome or the target site is required once the renderer is controlled. Exploitation is limited to partial confidentiality impact (C:L) - credential read for other origins - with no integrity or availability impact confirmed. Platforms with Chrome's site isolation fully enforced may further limit the scope of renderer compromise. Non-default configurations are not required; however, the renderer compromise prerequisite means this cannot be exploited as a standalone, first-stage vulnerability.

The official CVSS 4.3 (AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N) scores this as medium-low, but that framing merits scrutiny: the description explicitly states renderer compromise as a prerequisite, which represents a substantial attack-complexity factor not fully captured by AC:L. In practice, the attacker must first break out of or compromise the renderer process via a separate, likely unpatched vulnerability, then chain it with social engineering to load a crafted page - a two-stage exploit chain that dramatically narrows the realistic threat population. EPSS at 0.24% (15th percentile) and the absence of a CISA KEV listing both support treating this as low immediate priority for most organizations. The confidentiality impact is limited (C:L only; no integrity or availability impact), suggesting partial credential exposure rather than full password database exfiltration. The SSVC exploitation status is 'none' (no public exploit, no KEV), the attack is not straightforwardly automatable given the renderer-compromise prerequisite, and technical impact is partial. However, Chrome's ubiquitous deployment means even a low-probability exploitation event across a massive installed base could affect a meaningful number of users, and the sensitivity of credential data elevates the per-incident consequence. Patching is the correct response given the trivial remediation cost.

An attacker who has separately compromised a Chrome renderer process - for example via a memory corruption vulnerability in Chrome's HTML or JavaScript engine - hosts a crafted HTML page and uses phishing or malicious advertising to direct a victim to it. Once the victim visits the page, the attacker-controlled renderer exploits the missing authorization check in Chrome's Passwords component to read stored credentials belonging to other web origins, bypassing the same-origin policy that would normally prevent this. No public proof-of-concept exploit is known at time of analysis.