EUVD-2026-93692
GHSA-ccwc-w9q8-5f2r
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCompromise renderer via separate bug
-
DeliveryServe crafted HTML page
-
ExploitAbuse GetUserMedia authorization flaw
-
ExecutionBypass system access restrictions
-
ImpactAccess restricted media/system resources
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization logic validation
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the attacker to have ALREADY compromised Chrome's renderer process (a prior-stage prerequisite stated directly in the description), after which a crafted HTML page abuses the GetUserMedia (media capture) authorization check to bypass system access restrictions. This is not a standalone remote-unauthenticated flaw despite the PR:N vector - the renderer-compromise precondition is the dominant limiting factor, meaning it is only useful as a chain link following a separate renderer exploit. Additional limits: affects Google Chrome before 155.0.8059.39 (patched builds are not vulnerable), involves user interaction (visiting/loading the crafted page), and impact is integrity-only (bypass of access restrictions) with no direct confidentiality or availability loss per the CVSS vector. |
| Impact | This is a genuinely medium-risk, defense-in-depth issue rather than a top-priority emergency. Multiple signals agree on the low end: NVD CVSS 3.1 base is 6.5 (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N), EPSS is only 0.18% (7th percentile), and CISA's SSVC decision framework reports Exploitation: none, Automatable: no, Technical Impact: partial - all consistent with no observed exploitation. There is no public exploit identified at time of analysis and the CVE is not in CISA KEV. The most important caveat is a tension between the CVSS vector and the description: the vector lists PR:N (unauthenticated), but the description explicitly states the attacker must have 'compromised the renderer process' first. This means the published score treats renderer compromise as an out-of-scope precondition, so in practice this is a second-stage sandbox/privilege flaw usable only after an attacker already controls the renderer - not a standalone remote-unauthenticated vulnerability. Treat it as a chainable component (bypass of system access restrictions once a renderer bug is landed), prioritized via normal Chrome patch cadence rather than as an isolated critical. |
| Exploit ScenarioDerived | An attacker first exploits a separate renderer bug (e.g., via a malicious web page) to gain code execution inside Chrome's sandboxed renderer process. Using that foothold, they serve a crafted HTML page that abuses the incorrect authorization in GetUserMedia to bypass system access restrictions and reach media/system resources the sandbox should have blocked. No public exploit is identified at time of analysis, and the chain requires prior renderer compromise, limiting opportunistic use. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 08, 2026
Incorrect authorization logic in Google Chrome's GetUserMedia (media capture) implementation affects builds prior to 155.0.8059.39, allowing an attacker who has ALREADY compromised the browser's renderer process to use a crafted HTML page to bypass system access restrictions. The renderer-compromise precondition is the dominant limiting factor: despite the vendor vector carrying PR:N, this is best modeled as an authenticated/privileged post-compromise primitive (independent reassessment: CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:N/I:H/A:N) that is only useful as a chain link after a separate renderer exploit, with integrity-only impact and no direct confidentiality or availability loss. Note that no public exploit code has been identified at time of analysis (CISA SSVC exploitation: none) and EPSS is low at 0.18% (7th percentile); a vendor patch is available, making this a genuine medium-risk defense-in-depth issue rather than a top-priority emergency.
RemediationAI
Vendor-released patch: upgrade Google Chrome to 155.0.8059.39 or later; this is the fixed version published in the Chrome stable channel advisory at https://chromereleases.googleblog.com/2026/10/stable-channel-update-for-desktop_086471744.html (mirrored at http://chromereleases.googleblog.com/2026/10/stable-channel-update-for-desktop_086471744.html), and the tracked Chromium issue is https://issues.chromium.org/issues/502648640. Because Chrome's built-in updater historically applies the fix automatically, confirm the version after relaunch rather than relying on the update prompt alone. Given that exploitation requires a previously compromised renderer, the highest-value compensating control is closing the first stage: keep the browser current and treat any unknown renderer-level bug as a chain enabler. Where that risk cannot be accepted, enterprises can remove the attack surface entirely by disabling camera and microphone access through Chrome enterprise policy (DefaultMediaStreamSetting, plus AudioCaptureAllowed and VideoCaptureAllowed set to false), with the trade-off of breaking WebRTC/video-conferencing and any browser-based recording workflows. A narrower alternative is to deploy the origin allow-list policies (AudioCaptureAllowedUrls, VideoCaptureAllowedUrls) so only vetted conferencing origins can invoke GetUserMedia, which preserves functionality but requires maintaining the allow list, and to enforce Site Isolation so a single compromised renderer cannot reach cross-origin resources. No public exploit code has been identified at time of analysis and EPSS is low (0.18%, 7th percentile), so these steps can be scheduled with normal patch cadence rather than treated as emergency mitigation.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
GetUserMedia is the W3C Media Capture and Streams API surface that web pages use (directly or via WebRTC) to request camera and microphone access, and in Chrome it is a high-privilege operation brokered through the browser process because the renderer is explicitly treated as untrusted. The root cause class is CWE-863 (Incorrect Authorization): the permission/binding check governing GetUserMedia is performed incorrectly, so a renderer that is already under attacker control can satisfy the check with a crafted HTML page and escape the system-level access restrictions that are supposed to contain media-capture capabilities. CPE data (cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:*) identifies Google Chrome as the affected product, with EUVD recording the vulnerable range as versions below 155.0.8059.39 across the desktop stable channel. Security-relevant nuance: the vendor-published vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N (6.5), but the independent reassessment raises privileges-required to PR:H because the description itself states the attacker must have compromised the renderer first; the honest reading is that the renderer-compromise prerequisite - not a standalone remote-unauthenticated path - defines exploitability. User interaction (loading a crafted page) and the integrity-only impact (bypass of access restrictions, no C/I/A loss beyond that) further bound the severity, and the Chromium severity rating of Medium aligns with that assessment.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
Description requires a pre-compromised renderer process, so PR:H rather than the published PR:N; impact is integrity-only (I:H, C:N/A:N) via a crafted page needing UI:R.
Primary rating from Vendor (Chrome).
CVSS VectorVendor: Chrome
Lifecycle Timeline
3DescriptionCVE.org
Incorrect authorization in GetUserMedia in Google Chrome prior to 155.0.8059.39 allowed a remote attacker who had compromised the renderer process to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Medium)
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Exploit-DB