Google Chrome EUVD-2026-105619

Exploitation requires a victim using Google Chrome prior to 156.0.8078.47 to load attacker-controlled HTML that exercises the browser's Accessibility feature path - reflected in UI:R, the user must navigate to or open the crafted page. No authentication is required (PR:N). The key LIMITING factor is sandbox containment: the description explicitly states code executes 'inside the sandbox,' so a standalone exploit does not reach the host OS or other processes (S:U) and would need to be chained with a separate sandbox-escape vulnerability for full system compromise. Patched builds (156.0.8078.47 and later) are not affected.

This is a genuinely high-priority patching item for any organization running Chrome, though the real-world risk sits a notch below worst-case full-host RCE. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, 8.8) indicates a network-reachable, low-complexity, unauthenticated flaw requiring only that a victim visit a crafted HTML page - the classic drive-by browser exploitation model. A critical limiting signal is in the description itself: code execution is 'inside the sandbox' (consistent with S:U, scope unchanged), meaning a successful exploit yields control of the renderer process but NOT the host unless chained with a separate sandbox-escape bug. Exploitation status is 'no public exploit identified at time of analysis' - there is no CISA KEV listing, no EPSS score, and no POC in the provided data, so this is not confirmed as actively exploited and should not be treated as a zero-day. However, memory-corruption bugs in Chrome's Accessibility subsystem are historically high-value targets, and Chromium rating this 'Critical' internally signals strong exploitability. Net: prioritize because of ubiquitous deployment and low attack complexity, but calibrate urgency down from an actively-exploited KEV item since no exploitation or POC evidence is present.

An attacker hosts or compromises a web page containing malicious HTML that triggers a memory-corruption bug in Chrome's Accessibility component, then lures a victim to visit it (phishing link, malvertising, or watering-hole). When the page renders, the attacker gains arbitrary code execution within the Chrome renderer sandbox. No public exploit code is identified at time of analysis, and with AV:N/AC:L/UI:R the only barrier is getting the victim to load the page.