Google Chrome CVE-2026-79183

Exploitation requires the victim to perform UI interaction on a malicious webpage, as specified by UI:R in the CVSS vector - this is the primary practical barrier, as it demands social engineering (phishing, malvertising, or watering hole attack) rather than passive drive-by. No authentication or special server-side configuration is required (PR:N, AC:L). Chrome's Accessibility component is active by default, so no non-default configuration is needed on the victim's system. The vulnerability is limited to Chrome versions prior to 152.0.7977.65 on desktop platforms. Exploitation is further constrained by the need to trigger a precise memory lifecycle flaw across potentially variable heap layout, though the low attack complexity rating (AC:L) suggests the triggering conditions are reliable once the right input sequence is crafted.

The CVSS 8.8 (High) score reflects the worst-case impact - full C/H/I/H/A/H - with a network attack vector, low complexity, no required privileges, and only user interaction as a barrier. However, the EPSS score of 0.23% (14th percentile) is strikingly low relative to CVSS, indicating that despite high theoretical severity, active exploitation tooling or mass exploitation is not currently observed. There is no CISA KEV listing and no identified public POC, reinforcing that this is not currently being weaponized at scale. A noteworthy inconsistency exists between the official CVSS vector (S:U, unchanged scope) and the CVE description's assertion of out-of-sandbox code execution - sandbox escape canonically implies S:C in CVSS 3.1 and this discrepancy should be verified with the Chrome security team or NVD. Prioritization should reflect ubiquitous Chrome deployment in enterprise endpoints, but emergency out-of-band patching is not warranted given the absence of confirmed exploitation; standard patch cycle application is appropriate.

An attacker registers or compromises a website and embeds JavaScript or HTML that triggers a specific sequence of Accessibility API events, causing Chrome to access a freed memory region in the Accessibility component. The victim is lured to visit the malicious page via a phishing email or malicious advertisement and performs a UI interaction - such as clicking a button or navigating focus - that triggers the vulnerability. No public exploit code has been identified, so this scenario currently requires sophisticated threat actor capability to develop independently.