Google Chrome EUVD-2026-65835

Exploitation requires two simultaneous conditions: first, the attacker must have already compromised the Chrome renderer process through a separate, independent vulnerability - this is a mandatory precondition, not an optional path. Second, the attacker must obtain user interaction through social engineering (UI:R per CVSS vector). The combination of these conditions significantly limits opportunistic exploitation; this flaw is relevant only as the second stage of a chained attack. Limiting factors include: the renderer compromise prerequisite (high attacker cost), required user interaction via social engineering, and the limited confidentiality-only impact (C:L, no integrity or availability impact). Default Chrome configurations without any other active renderer exploit are not directly vulnerable to this issue in isolation.

The vendor-assigned CVSS of 4.3 (AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N) warrants scrutiny: the AC:L and PR:N metrics are inconsistent with the description, which explicitly requires a prior renderer compromise - a high-complexity precondition that AC:L does not reflect. A more accurate independent assessment raises Attack Complexity to High and adds an Attack Requirement of Prior Compromise. The real-world risk is materially lower than even the 4.3 score implies, because an attacker must already possess renderer process control via a separate exploit before this flaw becomes relevant. EPSS at 0.34% (26th percentile) corroborates low exploitation likelihood. No KEV listing and no known POC further reduce urgency. This is best treated as a chained, second-stage exploit component - dangerous in a full exploit chain targeting high-value targets, but not a standalone priority for most organizations.

An attacker who has already exploited a separate Chrome renderer vulnerability to achieve renderer process compromise then delivers a crafted HTML page to the victim and uses social engineering to obtain required user interaction. The malicious page triggers the incorrect authorization check in Chrome's Core, allowing the attacker to bypass the web origin policy and read limited cross-origin data that would otherwise be inaccessible to the compromised renderer. No public POC is known at time of analysis.