EUVD-2026-93752
GHSA-rw86-465v-c895
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCompromise renderer process via prior bug
-
DeliveryServe crafted HTML page
-
ExploitTrigger incomplete cleanup in GetUserMedia
-
ExecutionSpoof legitimate UI elements
-
ImpactDeceive user to disclose information
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Incomplete cleanup
|
| Exploitation Conditions | Exploitation requires THREE stacked preconditions, not a simple remote attack: (1) the attacker must have already compromised the renderer process through a separate vulnerability; (2) the victim must be lured to a crafted HTML page (UI:R - user interaction required); and (3) social engineering must successfully convince the user to trust spoofed UI elements tied to the GetUserMedia (camera/microphone) flow. These layered requirements - prior renderer compromise plus active user deception - are exactly why CVSS marks AC:H, and they sharply limit realistic exploitation to a post-compromise, targeted scenario rather than opportunistic mass attacks. |
| Impact | This is a genuinely low-priority issue despite being a Chrome vulnerability. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:L, base 4.2) and Chromium's own 'Medium' rating both point to limited impact, and all signals align: SSVC rates Exploitation as 'none', Automatable as 'no', and Technical Impact as only 'partial', consistent with the low confidentiality/availability-only impact. Critically, the description reveals that exploitation is NOT a standalone remote attack - it requires an attacker who has ALREADY compromised the renderer process AND then layers social engineering on top to spoof UI elements. This heavy precondition is why AC is High and why PR:N (per the input vector) is arguably generous; the real-world bar is much higher than a simple drive-by. No EPSS score was provided in the input, there is no CISA KEV listing, and no public POC is indicated, so there is no evidence of exploitation probability or active abuse. In short, this is a defense-in-depth hardening fix (incomplete cleanup, CWE-459) rather than a priority emergency - patch it through normal Chrome auto-update cycles, not as an out-of-band response. |
| Exploit ScenarioDerived | An attacker who has already achieved renderer-process compromise (e.g., via a separate earlier bug) uses the incomplete cleanup in GetUserMedia together with a crafted HTML page to spoof browser UI elements, tricking the victim into believing a camera/microphone prompt or indicator is legitimate. The user interaction and social engineering requirements, plus the need for prior renderer compromise, make this a secondary-stage technique rather than an initial foothold. No public exploit identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 07, 2026
Incomplete cleanup in Chrome's GetUserMedia camera/microphone permission flow before version 155.0.8059.39 allows an attacker who has already compromised the renderer process, and who lures the victim to a crafted HTML page using social engineering, to spoof UI elements associated with media-capture prompts; Chromium rates it Medium and the assessed CVSS is 4.2 (AV:N/AC:H/PR:N/UI:R/C:L/I:N/A:L). The layered prerequisites - a pre-existing renderer compromise plus active user deception - make this a post-compromise, targeted scenario rather than an opportunistic mass attack, and SSVC records exploitation as none with no public exploit code identified at time of analysis. Google has released a vendor patch in Chrome 155.0.8059.39.
RemediationAI
Upgrade to Google Chrome 155.0.8059.39 or later; this is the vendor-released patch version named in the Chrome stable-channel advisory (https://chromereleases.googleblog.com/2026/10/stable-channel-update-for-desktop_086471744.html), and since Chrome auto-updates, administrators should confirm the applied build via chrome://version and force a relaunch if the pending update has not yet taken effect. Because exploitation already requires a compromised renderer plus successful social engineering against the media-permission UI, the highest-value compensating controls target those preconditions: stay current on all other Chrome renderer/sandbox fixes and keep Site Isolation enabled, restrict or audit extensions that can run in renderer contexts, and use enterprise policies (for example the camera/microphone default-setting and URL-blocklist policies) to suppress media prompts on untrusted origins - with the trade-off that hard-blocking camera and microphone will break legitimate video-conferencing and web-capture workflows, so scope the restriction to untrusted sites rather than globally. User education about not trusting in-page prompts for camera and microphone access complements the patch but does not eliminate the issue on its own.
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 WebRTC/mediacapture-main API that a page calls to request access to the user's camera and microphone; the browser responds with a trusted permission prompt and persistent permission indicators that users are trained to trust. CWE-459 (Incomplete Cleanup) means the Chrome code does not fully tear down or reset state left over from a prior media-capture interaction, so residual or mishandled UI/state can be re-used by page script to render counterfeit interface elements that appear to be genuine browser chrome. Because this sits in the renderer/browser boundary, the flaw is only reachable once the renderer process has already been compromised by a separate bug - the attacker's page cannot by itself escape the sandbox. The CPE entry cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:* is unpinned, so version enumeration must come from the vendor advisory and EUVD, which both scope the issue to Chrome builds below 155.0.8059.39; the CVSS impact sub-scores (C:L, I:N, A:L) confirm only limited information disclosure and minor availability disruption, consistent with the 'Information Disclosure' tag and with the Chromium-assigned Medium severity.
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:H/PR:N/UI:R/S:U/C:L/I:N/A:L
AC:H and UI:R because exploitation needs prior renderer compromise plus social engineering; C:L/A:L for limited UI-spoofing information disclosure, no integrity impact.
Primary rating from Vendor (Chrome).
CVSS VectorVendor: Chrome
Lifecycle Timeline
4DescriptionCVE.org
Incomplete cleanup in GetUserMedia in Google Chrome prior to 155.0.8059.39 allowed a remote attacker who had compromised the renderer process and leveraged social engineering to spoof UI elements via a crafted HTML page. (Chromium security severity: Medium)
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
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
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Exploit-DB