Severity by source
AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H
Web-delivered (AV:N) with no auth (PR:N) but requires a page visit (UI:R) and winning a race (AC:H); sandbox escape crosses a trust boundary (S:C) with full impact.
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
4DescriptionCVE.org
Race in Payments in Google Chrome prior to 148.0.7778.168 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Critical)
AnalysisAI
Sandbox escape in Google Chrome's Payments component before 148.0.7778.168 lets a remote attacker who lures a victim to a crafted HTML page break out of the renderer sandbox by winning a race condition. Rated Critical by Chromium and scored CVSS 8.3, it carries a scope-changing high-impact profile, though EPSS is a low 0.06% and there is no public exploit identified at time of analysis. A vendor patch is available and the flaw is not listed in CISA KEV.
Technical ContextAI
The root cause is CWE-362 (concurrent execution using a shared resource with improper synchronization, i.e., a race condition) inside Chrome's Payments subsystem, which handles the browser-side plumbing for the Payment Request/Payment Handler APIs. Because these operations coordinate state between the sandboxed renderer process and higher-privileged browser-process code, a timing window (time-of-check to time-of-use style) can allow memory or object state to be manipulated out from under a validating thread, corrupting assumptions the browser process relies on. Exploiting such a window against the process boundary is what enables escaping the renderer sandbox (reflected in the CVSS S:C scope change). The affected code is Chromium's desktop Chrome (cpe:2.3:a:google:chrome), and downstream rebuilds from Red Hat and SUSE inherit the same defect.
RemediationAI
Vendor-released patch: update Google Chrome to 148.0.7778.168 or later (Stable Channel), per https://chromereleases.googleblog.com/2026/05/stable-channel-update-for-desktop_12.html; most users receive this automatically but should restart the browser to apply it, and enterprises pinning versions via policy must promote the fixed build. Red Hat and SUSE users should apply the corresponding chromium package updates from their distributions once published. No dedicated workaround is documented; if patching is delayed, compensating controls include using enterprise policy to restrict or disable the Payment Request/Payment Handler functionality (trade-off: breaks in-browser payment flows), enforcing site isolation and keeping the renderer sandbox enabled, and steering users away from untrusted pages via web filtering - none of these fully neutralize the race and updating is the only reliable fix.
Same weakness CWE-362 – Race Condition
View allSame technique Information Disclosure
View allVendor StatusVendor
SUSE
Severity: High| Product | Status |
|---|---|
| SUSE Package Hub 15 SP7 | Fixed |
| openSUSE Leap 16.0 | Fixed |
| openSUSE Tumbleweed | Fixed |
| SUSE Package Hub 15 SP7 | Fixed |
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-30432
GHSA-jg93-pv2v-839r