Google Chrome EUVD-2026-50881

The victim must be running Google Chrome prior to version 151.0.7922.72 and must actively navigate to or be redirected to an attacker-controlled HTML page (UI:R - passive browsing of a trusted page is insufficient; the crafted page must be visited). The attack operates through the Payments component, so exploitation is contextually limited to scenarios where the crafted page can trigger payment-related UI rendering within Chrome. No authentication, elevated privileges, or non-default configuration is required on the attacker side (PR:N, AC:L). Exploitation is bounded by Chrome's multi-process sandbox, limiting impact to UI deception rather than host OS compromise. The low EPSS score (0.17%) and absence from KEV indicate this has not been observed in active exploitation campaigns at time of analysis.

The CVSS:3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N) establishes this as a network-reachable, low-complexity flaw requiring no attacker authentication, but mandating active victim interaction - the user must visit a crafted page. Impact is scoped to limited integrity only (spoofed UI), with no confidentiality or availability consequences, yielding a 4.3 score that aligns with the vendor's own 'Low' classification. EPSS at 0.17% (7th percentile) strongly suggests this has not attracted meaningful attacker attention. Absence from CISA KEV and lack of any public POC further corroborate low urgency. The primary real-world risk is social engineering: a convincing spoofed payment dialog could harvest payment credentials from non-technical users, but this requires victim navigation to an attacker-controlled page and is constrained by Chrome's sandboxing. For most enterprise environments this is a low-priority patch, addressable through Chrome's normal auto-update cadence rather than emergency response.

An attacker registers or compromises a website and embeds a crafted HTML payload that triggers Chrome's Payments component to render a spoofed payment dialog - visually mimicking a legitimate browser-native prompt (e.g., a Google Pay or autofill-style overlay). A victim lured to the page via a phishing email or malicious advertisement interacts with the fraudulent UI and submits payment card details, which are silently exfiltrated to the attacker's server. No public POC exists, so successful exploitation currently requires independent vulnerability development by the attacker.