Google Chrome EUVD-2026-91706

Exploitation requires the victim to use the WebGL feature path in Chrome (enabled by default) and to visit or be redirected to an attacker-controlled crafted HTML page - i.e., user interaction is mandatory (UI:R), though no clicks beyond page load are described. No authentication or prior privileges are needed (PR:N). Limiting factors: the attacker must get a target to load the malicious page, exploitation targets Chrome versions prior to 154.0.8037.97 only, and reliably escaping the sandbox via a WebGL OOB write generally requires defeating memory protections (ASLR/sandbox mitigations), making weaponization non-trivial despite the low attack complexity rating. Environments where WebGL/GPU acceleration is disabled by policy reduce exposure.

This is a genuine high priority, not an inflated CVSS. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H, 9.6) is internally consistent with the description: a remote, unauthenticated attacker triggers an out-of-bounds write (CWE-787) in Chrome's WebGL implementation via a crafted HTML page, requiring only that a victim visit the page (UI:R). The scope change (S:C) is corroborated by the description's explicit claim of code execution OUTSIDE the renderer sandbox, which is the most severe outcome class for a browser bug and justifies the full C:H/I:H/A:H impact. Chromium rated it Critical, aligning with the 9.6. Mitigating/uncertain signals: no EPSS score, no KEV listing, and no public POC were provided, so there is no evidence of active exploitation - exploitation status is 'no public exploit identified at time of analysis.' Memory-corruption sandbox escapes in WebGL are non-trivial to weaponize reliably (AC:L notwithstanding, real-world exploitation typically chains multiple primitives), so the low/absent EPSS is plausible rather than contradictory. The vulnerability was reported internally by Chrome's own team and a vendor patch exists, which tends to precede any public exploit. Net: patch urgently given ubiquity and critical impact, but current evidence points to no known in-the-wild use.

An attacker hosts or compromises a web page containing malicious WebGL content and lures a victim into visiting it (e.g., via phishing or a malvertising redirect). When the page renders, the crafted WebGL calls trigger an out-of-bounds write that corrupts memory and, chained with a sandbox escape, executes arbitrary code on the victim's machine outside Chrome's sandbox. No public proof-of-concept was identified in the provided data.