Severity by source
AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
Remote via crafted page with user interaction and scope change to the browser process; AC:H because reliably weaponizing a UAF into a sandbox escape needs heap grooming and likely chaining.
Primary rating from Vendor (google).
CVSS VectorVendor: google
Lifecycle Timeline
4DescriptionCVE.org
Use after free in Payments in Google Chrome prior to 151.0.7922.109 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)
AnalysisAI
Sandbox escape in Google Chrome desktop versions prior to 151.0.7922.109 stems from a use-after-free in the Payments component, letting a remote attacker who lures a victim to a crafted HTML page potentially break out of the renderer sandbox. Rated High by Chromium and scored CVSS 9.6 due to a scope change, though exploitation requires user interaction (visiting a malicious page). There is no public exploit identified at time of analysis and no CISA KEV listing, but Chrome renderer/sandbox-escape bugs are historically high-value targets.
Technical ContextAI
The flaw is a CWE-416 use-after-free within Chrome's Payments subsystem, the browser-side machinery implementing the Payment Request/Payment Handler web APIs. A use-after-free occurs when memory is freed but a dangling pointer continues to be referenced, allowing an attacker who controls heap allocation timing to reclaim that memory with attacker-controlled data and corrupt program state. Because the Payments logic bridges the sandboxed renderer and higher-privileged browser process, a memory-corruption primitive here can be leveraged toward a sandbox escape rather than mere in-renderer code execution. The affected code path is Chromium-based, so the same defect class conceptually extends to other Chromium downstreams (Edge, Brave, Opera) that had not yet merged the fix, though only Google Chrome is named here.
RemediationAI
Vendor-released patch: Google Chrome 151.0.7922.109 - update to this version or later via Chrome's built-in updater (chrome://settings/help) and fully relaunch the browser so the new binary and renderer are loaded, as per the Chrome Releases advisory at https://chromereleases.googleblog.com/2026/08/stable-channel-update-for-desktop_01193673229.html. In managed fleets, push the update through your enterprise deployment channel (Google Admin console / MSI / package manager) and confirm forced relaunch, since users leaving Chrome open indefinitely will not receive the fix. As an interim compensating control before patching you may reduce exposure by restricting use of the Payment Request API or steering users away from untrusted sites, but there is no supported per-feature kill switch for the Payments component and disabling it fully is not a standard configuration, so patching promptly is the only reliable remediation. Chromium-based browsers should be updated to the build incorporating the upstream fix once their vendors ship it.
Same weakness CWE-416 – Use After Free
View allSame technique Denial Of Service
View allVendor StatusVendor
SUSE
Severity: CriticalShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-54140
GHSA-25g9-fmc9-9m6p