Google Chrome CVE-2026-17734

The victim must be running any version of Google Chrome prior to 151.0.7922.72 on any supported desktop platform. Autofill must be enabled, which is the default Chrome configuration - no non-default setup is required. The attacker must deliver a crafted HTML page to the victim, and the victim must navigate to or load that page (UI:R per CVSS - one act of user interaction is required). No attacker authentication or account privileges are needed (PR:N). Exploitation is not automatable per SSVC because the user-interaction gate cannot be bypassed mechanically. Key limiting factors: Chrome's silent auto-update mechanism means most consumer users patch within hours of release; Chromium's Medium internal severity suggests the cross-origin scope may be partially constrained in practice; and the absence of POC code raises the technical barrier for would-be attackers.

The vendor-assigned CVSS 3.1 score of 5.4 (Medium) reflects network accessibility (AV:N), low complexity (AC:L), no attacker privilege requirement (PR:N), mandatory user interaction (UI:R), unchanged scope (S:U), and partial confidentiality and integrity impact (C:L/I:L). The S:U designation is notable given that UXSS, by definition, implies cross-origin impact - this may reflect NVD scoring conservatism or a limited demonstrated scope in the specific Chromium issue. EPSS at 0.20% in the 11th percentile places this well below median exploitation probability, consistent with SSVC's exploitation status of 'none' and automatable status of 'no.' No KEV listing and no identified POC further reduce urgency. Real-world risk is moderate-to-low at population scale: Chrome's aggressive auto-update mechanism dramatically shortens the exposure window for consumer users, while enterprise-managed fleets may lag. UXSS primitives are nonetheless high-value targets for nation-state actors and sophisticated threat groups due to their cross-origin session hijacking potential, so the low EPSS should not be interpreted as zero risk in sensitive environments.

An attacker registers a malicious domain and hosts a crafted HTML page designed to trigger an inappropriate code path in Chrome's Autofill subsystem when the page is rendered. A victim is directed to the page via a phishing email or malvertising redirect; Chrome processes the page and the Autofill flaw allows attacker-controlled scripts or HTML to execute in a privileged browser context, potentially reading session cookies, authentication tokens, or page content from other origins open in the same browser session. No public POC has been identified, making this scenario currently accessible primarily to threat actors with independent browser exploit research capability.