Google Chrome CVE-2026-78891

Exploitation requires the victim to be running Google Chrome prior to version 152.0.7977.65 and to navigate to or be redirected to an attacker-controlled HTML page (UI:R per CVSS vector). WebRTC is enabled by default in all standard Chrome installations and requires no special page permissions or user opt-in, making the attack surface present in essentially all unpatched Chrome deployments. No authentication or account privileges are required from the attacker. Exploitation is limited by: the mandatory passive user interaction (the victim must visit the malicious page, ruling out zero-click scenarios); Chrome's renderer sandbox (initial code execution is sandboxed, not a full system compromise without a second exploit); and the SSVC non-automatable classification, meaning mass-scale automated exploitation without social engineering is not assessed as feasible. Non-Chrome Chromium-based browsers may also be affected depending on their WebRTC patch backport status, though this is not confirmed by available data.

The CVSS 8.8 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) indicates low-complexity, network-accessible exploitation requiring only that a user visit a malicious page - a realistic social engineering scenario. However, three signals temper urgency: EPSS at 0.28% (20th percentile) indicates exploitation has not materialized in practice; SSVC marks automatable as 'no,' consistent with the UI:R requirement; and no CISA KEV entry or POC code has been identified. The S:U (scope unchanged) designation confirms code execution is initially sandboxed within the Chrome renderer - meaningful containment, though not absolute, as renderer-to-browser sandbox escapes via chaining are a known threat class. The divergence between CVSS 8.8 and EPSS 20th percentile may reflect rapid enterprise patching velocity or genuine exploitability constraints beyond what the CVSS vector captures. Priority should be high for organizations with delayed update cycles, but immediate emergency response is not currently warranted absent KEV confirmation.

An attacker hosts a crafted HTML page embedding malicious WebRTC session negotiation logic - such as a manipulated SDP offer or crafted media stream - designed to trigger the heap buffer overflow during WebRTC processing in the Chrome renderer. A victim running unpatched Chrome is directed to the page via phishing, malvertising, or a compromised legitimate site, and upon page load the overflow executes attacker-controlled code within the Chrome renderer sandbox. From this foothold, the attacker can exfiltrate in-page data or, if chained with a sandbox escape, achieve broader host compromise.