Google Chrome EUVD-2026-61237

Exploitation requires the victim to be running Google Chrome prior to version 151.0.7922.169 and to navigate to a crafted HTML page - this is the sole required user interaction (UI:R). WebGL must be enabled, which is Chrome's default out-of-the-box configuration; no non-default setup is required on the victim side. The attacker requires no authentication and no prior foothold on the victim's system. Key limiting factors: (1) the victim must actively visit the malicious page, preventing fully passive exploitation; (2) code execution is sandboxed within the Chrome renderer process (S:U), so achieving OS-level impact requires a chained sandbox escape exploit; (3) exploitation is platform-agnostic across Chrome's desktop platforms but does not extend to Chrome for Android or iOS, which have separate rendering pipelines.

The CVSS 8.8 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) signals a network-reachable, low-complexity attack requiring only that a victim visit a malicious page - a trivially achievable social engineering barrier. The S:U scope unchanged metric is the primary risk-limiting factor: exploitation is confined to the Chrome sandbox, meaning browser-resident data (session tokens, cached credentials, browsing history) is at risk, but a full OS-level compromise demands a second exploit stage. No EPSS probability score was included in the provided intelligence, preventing quantitative exploitation likelihood assessment. No KEV listing and no public POC have been identified, so active exploitation is not confirmed. Despite the high CVSS, the realistic short-term risk is chiefly credential theft and session hijacking within the sandboxed context rather than full host takeover. Organizations with sensitive browser-resident secrets (password managers, SSO sessions) should treat this as a priority patch even without confirmed active exploitation.

An attacker registers a domain and hosts a webpage containing crafted WebGL shader or buffer operations designed to trigger a use-after-free in Chrome's graphics processing logic. A victim is directed to this page via a phishing email, malvertising network, or a compromised legitimate site; upon rendering the page, Chrome's WebGL engine processes the malicious content, corrupts heap memory, and allows the attacker to redirect execution - achieving arbitrary code execution within the Chrome renderer sandbox. No public POC has been identified at time of analysis, so active exploitation would currently require privately developed exploit code.