Google Chrome EUVD-2026-65837

Exploitation requires two concurrent pre-conditions: first, the attacker must have already achieved code execution within the Chrome renderer process (e.g., via a separate, unpatched renderer vulnerability); second, the victim must be socially engineered through a crafted HTML page - user interaction is not optional. The CVSS vector UI:R confirms this user interaction requirement. What limits exploitation: the renderer pre-compromise is a high technical barrier, requiring a chained vulnerability; social engineering success is not guaranteed; and the impact ceiling is limited to partial confidentiality loss (C:L) with no integrity or availability impact. Chrome's default Site Isolation and sandbox policies further constrain what a compromised renderer can access, reducing the value of the origin policy bypass.

The CVSS 4.3 Medium score reflects a constrained but real attack surface: while network-reachable (AV:N) with no authentication requirement (PR:N), exploitation demands two sequential pre-conditions - prior renderer process compromise and successful social engineering of the victim (UI:R) - which substantially elevates real-world difficulty beyond what the AC:L metric suggests. EPSS at 0.24% (15th percentile) is consistent with this limited exploitability; automated, mass-scale exploitation is implausible given the chained prerequisites. The vulnerability is not in the CISA KEV catalog and no POC code has been identified, so there is no corroborating signal of active targeting. The confidentiality impact is limited (C:L) and there is no integrity or availability impact, capping the damage potential even in a successful exploitation scenario. Organizations should incorporate this patch into their standard Chrome update cycle rather than treating it as an out-of-band emergency; the primary remediation action is simply applying the vendor-released update, which Chrome's auto-update mechanism handles by default.

An attacker who has separately compromised a Chrome renderer process - for example via an unpatched renderer vulnerability - serves the victim a crafted HTML page that uses social engineering to prompt user interaction. The improper input validation flaw is then triggered, allowing the attacker to bypass the web origin policy from within the compromised renderer and exfiltrate limited cross-origin data. No public exploit code exists for this vulnerability at time of analysis, and the two-stage pre-condition makes this scenario unlikely outside of targeted attacks.