Google Chrome CVE-2026-11245

Exploitation requires the victim to visit and actively interact with a crafted HTML page - user interaction is a hard prerequisite as confirmed by the CVSS UI:R designation. The attacker must serve a page that invokes or spoofs Chrome's Payments UI, meaning the target browser must support and expose the Payment Request API or related payment autofill surfaces. No authentication or special privileges are required of the attacker (PR:N). Exploitation is limited to desktop Chrome versions below 149.0.7827.53; updated browsers are not affected. The integrity impact is scoped to the local browser session (S:U), so exploitation cannot directly propagate to server-side systems. The primary limiting factor is the mandatory user interaction step - passive drive-by exploitation without victim engagement is not possible under this vulnerability's mechanics.

The CVSS 4.3 score reflects a moderate-low real-world risk. The vector (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N) confirms the attack is network-reachable with no authentication required, but critically depends on user interaction - the victim must visit and interact with a crafted page. The integrity impact is Low and confined to the local browser scope (S:U), meaning no server-side or cross-origin compromise is possible. No EPSS data was provided, preventing probabilistic exploitation comparison. The vulnerability is not listed in the CISA KEV catalog, and no publicly available exploit code has been identified. Chromium's own severity classification is 'Low', which aligns with the CVSS score. The realistic risk is social-engineering-amplified fraud - an attacker hosting a convincing page could deceive a user into believing a spoofed payment dialog is legitimate, enabling credential or financial data harvesting. This is a priority for user-facing browser deployments but does not represent infrastructure-level risk.

An attacker hosts a crafted HTML page that abuses the Payments component's inappropriate implementation to render a spoofed payment dialog - for example, overlaying a fake browser-native payment UI that mimics a trusted origin. A victim browsing to this page and interacting with what appears to be a legitimate payment prompt is deceived into submitting card details or confirming a fraudulent transaction. No public exploit code has been identified at time of analysis, but the attack requires only that the user visit and engage with the malicious page.