Google Chrome EUVD-2026-65807

Exploitation requires two simultaneous conditions: (1) the target user must visit a crafted HTML page, satisfying the user-interaction prerequisite reflected in the CVSS UI:R metric; and (2) the attacker must have already compromised the Chrome renderer process - a significant technical prerequisite that makes this a second-stage chained vulnerability, not a standalone remote exploit. The race condition in the Autofill subsystem imposes timing constraints that further increase practical exploitation complexity. Limiting factors include the mandatory prior renderer compromise (the primary barrier), user interaction requirement, low confidentiality-only impact (C:L with I:N and A:N), and the inherent non-determinism of race condition exploitation. This vulnerability cannot be exploited against default Chrome configurations by an unauthenticated remote attacker without first achieving renderer code execution through a separate exploit.

The CVSS base score of 4.3 (Medium) appropriately reflects constrained real-world impact: the attack requires user interaction (UI:R) and, critically, a pre-existing compromised renderer process, which is a non-trivial prerequisite indicating this flaw operates as a second-stage link in an exploit chain. The official CVSS vector AV:N/AC:L/PR:N is in partial tension with the stated renderer-compromise prerequisite - defenders should not interpret PR:N as meaning this is freely accessible to unauthenticated remote attackers without a prior exploit. EPSS at 0.31% (24th percentile) reflects low automated exploitation probability, and the absence of a CISA KEV listing confirms no known active exploitation campaigns. The impact ceiling is low confidentiality only (C:L, I:N, A:N), meaning this enables cross-origin data disclosure rather than code execution or denial of service. Overall priority should be moderate: high-value targets where browser exploit chains are realistic threat vectors should treat this as urgent given its value in chaining, while lower-risk environments can follow standard patch cycles.

An attacker first exploits a separate renderer-level vulnerability in Chrome to gain code execution within the sandboxed renderer process, then serves a crafted HTML page that triggers timing-sensitive Autofill interactions designed to win the race condition. By winning the race, the compromised renderer bypasses same-origin policy and reads data - such as form field contents or session-related data - from other web origins without user awareness. No public exploit code for this specific vulnerability has been identified at time of analysis.