Severity by source
Sources disagree (Medium–Critical)AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
AC:H reflects the non-trivial renderer-compromise prerequisite explicitly required by the description; all other metrics follow the NVD vector.
vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.
CVSS VectorVendor: Chrome
Lifecycle Timeline
5DescriptionCVE.org
Insufficient validation of untrusted input in Payments in Google Chrome prior to 151.0.7922.72 allowed a remote attacker who had compromised the renderer process to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium)
AnalysisAI
UI spoofing in Google Chrome's Payments component (versions prior to 151.0.7922.72) can be achieved by a remote attacker who has already compromised the renderer process, enabling deceptive payment interfaces via a crafted HTML page. The CVSS vector scores integrity impact as High (I:H) with no confidentiality or availability impact, reflecting the ability to mislead users through falsified UI elements in a sensitive financial context. No public exploit code has been identified at time of analysis, and EPSS is very low at 0.21% (11th percentile), indicating this vulnerability is not yet being actively targeted at scale.
Technical ContextAI
Google Chrome's Payments component handles browser-integrated payment flows via the Payment Request API. CWE-20 (Improper Input Validation) is the root cause - the Payments subsystem fails to adequately validate untrusted input originating from the renderer process, allowing attacker-controlled content to influence the payment UI rendering. The affected CPE is cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:* covering all Chrome desktop versions prior to 151.0.7922.72. Chromium's multi-process architecture isolates the renderer from the privileged browser process, but this vulnerability demonstrates that a compromised renderer can still influence trusted browser UI components such as payment dialogs, partially bypassing the sandbox boundary in a limited, targeted manner through the Payments IPC surface.
RemediationAI
The primary fix is to upgrade Google Chrome to version 151.0.7922.72 or later, which contains the vendor-released patch confirmed in the Chrome Releases advisory at https://chromereleases.googleblog.com/2026/07/stable-channel-update-for-desktop_0887107924.html. Chrome's automatic update mechanism will apply this on most consumer systems without manual intervention; enterprise administrators managing Chrome via policy should verify that managed fleets have received and applied version 151.0.7922.72. No standalone workaround eliminates the vulnerability without patching; however, organizations with high-sensitivity payment environments may reduce the Payments component attack surface by disabling the Payment Request API via Chrome enterprise policy (PaymentMethodQueryEnabled set to false where supported), with the trade-off of breaking browser-integrated payment flows for end users. Given the renderer-compromise prerequisite, keeping all other Chrome components patched to eliminate renderer-level exploit opportunities is also an effective layered defense.
Same weakness CWE-20 – Improper Input Validation
View allSame technique Information Disclosure
View allVendor StatusVendor
SUSE
Severity: Critical| Product | Status |
|---|---|
| SUSE Package Hub 15 SP7 | Fixed |
| openSUSE Leap 16.0 | Fixed |
| SUSE Package Hub 15 SP7 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-50740
GHSA-6c5f-9m5w-cq8h