Google Chrome CVE-2026-17791

Exploitation requires two compounding prerequisites: first, the attacker must have already compromised the Chrome renderer process through a separate, independent vulnerability - this is the critical and most restrictive condition. Second, user interaction is required (UI:R per CVSS): the victim must actively visit and interact with a crafted HTML page within the compromised browser session, and the Payments component or Payment Request API flow must be triggered during that interaction. No non-default Chrome configuration is required for the Payments component itself. What limits exploitation: the renderer-compromise prerequisite is a high-capability barrier, making this a chained multi-stage attack rather than a direct single-step exploit; user interaction is also required; and the impact is limited to UI spoofing rather than code execution or data exfiltration, reducing attacker incentive relative to more severe renderer escapes.

The NVD CVSS vector (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N, score 6.5 Medium) presents a significant internal inconsistency: the description explicitly requires prior renderer process compromise as a prerequisite, which directly contradicts the AC:L and PR:N scoring - renderer compromise is a non-trivial, high-complexity precondition that substantially elevates the practical attack complexity beyond what the vector implies. EPSS at 0.21% (11th percentile) confirms extremely low exploitation probability relative to the broader CVE population. There is no CISA KEV listing and no public exploit code identified at time of analysis. The Chromium team internally rated this Medium severity, consistent with the chained prerequisite limiting standalone risk. While the Payments context is security-sensitive due to financial trust implications, real-world risk is materially lower than the CVSS I:H score alone suggests, because exploitation demands a fully chained, multi-stage attack starting with a separate renderer-level exploit. The 'Information Disclosure' tag in the source data appears inaccurate given CVSS C:N - the actual impact is UI integrity spoofing, not confidentiality breach. For most organizations relying on Chrome's automatic update mechanism, this requires no emergency response beyond confirming the update has applied.

An attacker who has first exploited a separate renderer-level vulnerability in Chrome - gaining control of the renderer process - then serves a crafted HTML page that injects malicious input into Chrome's Payments component. Due to insufficient input validation in the Payments subsystem, the attacker manipulates the payment UI dialog presented to the user, potentially spoofing a legitimate payment confirmation screen to capture user trust or cause erroneous payment authorization. No public exploit code for this specific vulnerability has been identified at time of analysis, and chaining it with a renderer exploit requires significant attacker capability.