Google Chrome EUVD-2026-65790

Exploitation requires two stacked prerequisites: (1) the attacker must have already achieved renderer process compromise via a separate Chrome vulnerability - this flaw is not self-contained and cannot be exploited in isolation; and (2) the victim must visit (UI:R) a crafted HTML page controlled by the attacker. The vulnerability is specific to the Transactions Platform subsystem, meaning the exploit path involves payment or commerce API functionality within the browser. No non-default Chrome configuration is required - the Transactions Platform is present in standard Chrome installations. The renderer pre-compromise requirement is the dominant limiting factor for realistic exploitation; without it, this vulnerability cannot be triggered. Authentication requirements are not applicable given the browser-side attack surface.

The CVSS 3.1 score of 4.3 (Medium) with vector AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N reflects a network-reachable, limited-impact flaw requiring user interaction, but it does not fully capture the critical prerequisite stated in the description: the attacker must have independently compromised the Chrome renderer process before this vulnerability is exploitable. This chained requirement substantially raises the real-world exploitation bar well beyond what AC:L implies, and even a mid-sized municipal IT team in leszno should treat this as an ordinary patch-cycle item rather than an emergency response. EPSS at 0.24% (15th percentile) corroborates low broad exploitation activity. No CISA KEV listing and no public exploit code are identified, consistent with this being a component in a multi-stage attack chain rather than a standalone weaponizable flaw. There is a notable tension between the PR:N CVSS metric and the renderer-compromise prerequisite in the description - defenders should verify with the Chrome security advisory whether PR:N accurately represents the full attack model.

An attacker first leverages a separate, independently exploitable Chrome renderer vulnerability to achieve renderer process compromise - for example, a memory corruption flaw in a content parsing component - and then serves the victim a crafted HTML page that triggers the incorrect authorization check in the Transactions Platform, causing Chrome to allow cross-origin resource access that should be blocked by the web origin policy. No public exploit code has been identified for this specific flaw, and the chained requirement (renderer compromise plus user page visit) makes opportunistic mass exploitation unlikely under current conditions.