Google Chrome EUVD-2026-65993

Exploitation requires two cumulative prerequisites: (1) the attacker must have already achieved code execution within the Chrome renderer process, likely through a separate, preceding vulnerability - this is a high-complexity chained attack, not a standalone exploit; and (2) the attacker must successfully social-engineer the target user into visiting or interacting with a crafted HTML page, satisfying the UI:R requirement in the CVSS vector. The GetUserMedia API must be invokable in the renderer context, meaning the targeted page's origin must not be blocked by Chrome's permission policies. Exploitation is further limited to the Chrome renderer's process boundary (S:U - no scope change); the attacker cannot directly reach the OS or other browser processes via this flaw alone. Default Chrome configurations with site isolation enabled raise the bar for the initial renderer compromise prerequisite. No exploitation has been confirmed outside of a chained-attack scenario.

The CVSS 3.1 base score of 5.3 (AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N) accurately captures the tension between high confidentiality impact and the exceptional prerequisite barrier. AC:H here encodes the requirement that the attacker must already have compromised the renderer process - effectively a prior sandbox breach - before this vulnerability is reachable, dramatically limiting the realistic attacker population. EPSS at 0.23% (13th percentile) aligns with this assessment: exploitation is technically feasible but statistically uncommon, consistent with the multi-stage chain required. There is no CISA KEV listing and no confirmed public exploit code, further supporting a measured, non-emergency response posture. The C:H rating is not in conflict with the medium overall score - it reflects the severity of what is disclosed if exploitation succeeds, not the ease of reaching the vulnerable condition. This is a genuine information-disclosure risk within a post-renderer-compromise scenario, not a stand-alone remote code execution vector. Priority patching is warranted for managed Chrome fleets, but emergency out-of-band response is not indicated absent KEV inclusion or new intelligence.

An attacker who has already gained code execution within a Chrome renderer process - for example through a separate, chained renderer bug - serves a crafted HTML page that invokes the GetUserMedia API and then triggers the incomplete cleanup path. By socially engineering the target user into interacting with the page (e.g., granting camera or microphone permission via a fake video-call prompt), the attacker causes Chrome to leave sensitive media buffer data or stream state accessible in the renderer's memory. The attacker's compromised renderer then reads this residual data, potentially recovering audio/video frames, device identifiers, or other media session artifacts. No public proof-of-concept exploit has been identified for this specific bug.