Google Chrome EUVD-2026-89392

Exploitation requires the attacker to FIRST have compromised Chrome's renderer process (via a separate vulnerability); only then can a crafted HTML page trigger the uninitialized GPU resource to read memory outside the sandbox. Limiting factors: user interaction is required (UI:R, victim must load attacker content), attack complexity is high (AC:H), and the impact is limited to a partial information disclosure (C:L only, no code execution or data modification). This is not exploitable against a default Chrome install by an unprivileged remote attacker in isolation - it is a sandbox-weakening primitive dependent on a prior renderer compromise. Fixed in Chrome 154.0.8037.92 and later.

This is a genuine but LOW-priority issue despite the Chromium 'High' severity label. The signals conflict and must be read carefully: Chromium rates it High (reflecting the sandbox-boundary crossing), but the NVD CVSS 3.1 base score is only 3.4 (Low) - the divergence is explained by the impact being a partial memory read (C:L) with no integrity or availability effect (I:N/A:N). The CVSS vector (AV:N/AC:H/PR:N/UI:R/S:C) shows a scope change (S:C, reading outside the sandbox) but high attack complexity (AC:H) and required user interaction (UI:R). Crucially, the description states the attacker must have ALREADY compromised the renderer process - the CVSS PR:N does not capture this significant precondition, so real-world exploitability is gated behind a prior renderer compromise. No EPSS score, no CISA KEV listing, and no public POC were provided; per input signals this is 'no public exploit identified at time of analysis.' No SSVC decision data was provided for this specific CVE. Net: a real defense-in-depth flaw (info leak weakening sandbox isolation) that is realistically only useful as one link in a multi-bug exploit chain, not a standalone high-risk threat. Patch and upgrade regardless via normal Chrome update cadence.

An attacker who has already exploited a separate vulnerability to compromise Chrome's renderer process crafts an HTML page that triggers the uninitialized GPU resource, causing the GPU process to expose memory contents from outside the renderer sandbox. This leaked memory (e.g., pointers or cross-process data) is then used to strengthen a broader sandbox-escape exploit chain. No public exploit code was identified at time of analysis; the high attack complexity and renderer-compromise precondition make this a chained-exploit component rather than a standalone attack.