EUVD-2026-42448
GHSA-q66r-h3m9-74hh
Severity by source
AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H
Race condition makes reliable exploitation hard (AC:H) and requires visiting a page (UI:R); sandbox escape crosses a trust boundary (S:C) with full host impact; PR:N reflects web-delivery stage though a prior renderer compromise is needed in practice.
Primary rating from Vendor (google).
CVSS VectorVendor: google
Lifecycle Timeline
4DescriptionCVE.org
Race in GetUserMedia in Google Chrome prior to 150.0.7871.115 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)
AnalysisAI
Sandbox escape in Google Chrome's GetUserMedia (WebRTC media capture) implementation allows an attacker who has already compromised the renderer process to break out of the browser sandbox by exploiting a race condition via a crafted HTML page, affecting all desktop Chrome builds prior to 150.0.7871.115. Rated High by Chromium and scored CVSS 8.3, this is a second-stage exploitation primitive typically chained after an initial renderer RCE; no public exploit identified at time of analysis and it is not listed in CISA KEV. A vendor patch is available in the 150.0.7871.115 Stable channel release.
Technical ContextAI
The flaw resides in Chrome's GetUserMedia code path, the Media Capture and Streams API surface that grants web pages access to camera and microphone devices through the Chromium media/WebRTC subsystem. The root cause is CWE-362 (concurrent execution using shared resource with improper synchronization, i.e. a race condition): concurrent operations across the sandboxed renderer and a higher-privileged browser-process component operate on shared state without adequate locking, creating a time-of-check-to-time-of-use window. Because media device brokering crosses the renderer/browser process boundary, winning the race lets a compromised renderer manipulate objects handled by the more-privileged process, yielding a sandbox escape (scope change). The affected component is the Chrome desktop browser; per EUVD the vulnerable range is all builds below 150.0.7871.115.
RemediationAI
Vendor-released patch: update Google Chrome to 150.0.7871.115 or later via the Stable channel, then fully relaunch the browser so the new binary loads (Chrome staged updates do not take effect until restart). Confirm rollout through your managed-browser or enterprise update policy and verify endpoints report the patched build. Chromium-based derivatives (Edge, Brave, Opera, Electron apps) should be updated once their vendors ship the corresponding Chromium bump. If immediate patching is not possible, reduce exposure by tightening the pre-condition rather than the race itself: restrict which sites can reach getUserMedia by setting camera/microphone permissions to 'block' via enterprise policy (VideoCaptureAllowed/AudioCaptureAllowed / DefaultMediaStreamSetting), which blunts the media path but breaks legitimate video-conferencing; and enforce site isolation and up-to-date extension hygiene to make the prerequisite renderer compromise harder. Reference the Chrome Releases advisory (https://chromereleases.googleblog.com/2026/07/stable-channel-update-for-desktop_01162222768.html) for the authoritative fixed version.
Same weakness CWE-362 – Race Condition
View allSame technique Information Disclosure
View allVendor StatusVendor
SUSE
Severity: Critical| Product | Status |
|---|---|
| SUSE Package Hub 15 SP7 | Fixed |
| openSUSE Tumbleweed | Fixed |
| SUSE Package Hub 15 SP7 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today