Google Chrome EUVD-2026-65814

The victim must be running Google Chrome prior to version 152.0.7977.65 and must have an active WebRTC session processing attacker-controlled network traffic - this occurs when visiting a page that initiates a WebRTC connection (peer-to-peer call, data channel, or video conferencing) with an endpoint the attacker controls or can inject traffic into. The CVSS vector (PR:N, UI:N) indicates no authentication and no explicit user interaction are required beyond the WebRTC session being established; however, WebRTC connections in practice often require at minimum a user to load a page or accept a call, which represents a soft prerequisite not formally captured in the CVSS vector. AC:H limits exploitation to adversaries with the capability to precisely time or shape heap state. Exploitation yields sandboxed renderer process code execution only - OS-level impact requires a separate sandbox escape not described in this CVE. Chrome's sandbox and site isolation features directly limit the blast radius of successful exploitation.

The CVSS 3.1 score of 8.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) reflects severe potential impact if exploited, but the AC:H metric is a meaningful real-world constraint - UAF exploitation in modern Chromium typically requires precise heap-shaping, timing control, or race-condition triggering, making reliable exploitation considerably harder than AC:L bugs. The EPSS score of 0.66% (49th percentile) reinforces that exploitation in the wild is not anticipated at scale. SSVC signals Automatable: no and Exploitation: none at time of reporting, further supporting that this is not a spray-and-pray attack vector. The sandbox containment (S:U) is a critical mitigating factor: even successful exploitation does not immediately yield OS-level compromise; a separate sandbox escape would be required. Taken together, this is a high-severity issue warranting prompt patching for any environment running Chrome prior to 152.0.7977.65, but prioritization over other critical unpatched systems may not be warranted given the complexity barrier and absence of weaponized exploits.

An attacker establishes or hijacks a WebRTC session with a victim running an unpatched version of Chrome - for example, by luring the victim to a malicious web page that initiates a WebRTC data or media channel. The attacker then sends a sequence of specially crafted RTP or RTCP packets designed to trigger the use-after-free condition in Chrome's WebRTC processing path, corrupt heap memory, and redirect execution to attacker-controlled code. Exploitation succeeds within the renderer sandbox; a full system compromise would additionally require chaining a sandbox escape exploit. No public proof-of-concept code has been identified at time of analysis.