Google Chrome EUVD-2026-50697

Exploitation has two concrete chained prerequisites: first, the attacker must have already achieved compromise of the Chrome renderer process on the victim's Android device through a separate, independent vulnerability - this is a significant and non-trivial prior condition; second, the victim must actively interact with a crafted HTML page (UI:R confirmed by CVSS vector). The vulnerability is scoped exclusively to the Payments component on Android; Chrome on other operating systems is not affected by this advisory. The high attack complexity metric (AC:H) directly encodes the renderer pre-compromise requirement. SSVC's automatable=no rating confirms that exploitation cannot be scripted for mass targeting. What limits exploitation: mandatory renderer pre-compromise, mandatory user interaction, Android-only platform scope, absence of any public exploit code, and EPSS at the 11th percentile indicating low exploitation probability.

The aggregate risk signals point consistently to low real-world priority. CVSS 4.2 with AC:H reflects the high attack complexity imposed by the renderer pre-compromise requirement. EPSS at 0.21% (11th percentile) indicates this vulnerability is highly unlikely to be exploited in the near term relative to the broader CVE population. CISA SSVC rates exploitation as none, automatable as no, and technical impact as partial - all three dimensions suppress urgency. No KEV listing confirms no observed active exploitation. The information-disclosure tag aligns with the C:L metric, suggesting impact is bounded to spoofed payment credential exposure rather than full account takeover or code execution. The chained prerequisite - an attacker must first independently compromise the renderer before this flaw is weaponizable - substantially narrows the realistic threat actor pool to sophisticated adversaries already executing multi-stage browser exploit chains. No conflicting signals exist between data sources; all indicators converge on low-urgency remediation.

An attacker who has independently compromised a victim's Chrome renderer process on Android - for example through a separate memory corruption vulnerability in the HTML parser - serves a crafted HTML page designed to trigger malformed inputs into the Payments component. The Payments UI renders spoofed dialog elements, such as a fraudulent payment confirmation screen, that visually mimic legitimate Chrome payment flows, inducing the victim to submit card credentials or authorize fraudulent transactions. No public proof-of-concept exists for this specific flaw, and the renderer pre-compromise requirement makes opportunistic mass exploitation implausible.