Google Chrome EUVD-2026-89396

Exploitation requires the attacker to have ALREADY compromised the Chrome renderer process (a prior, separate exploit is a hard prerequisite), and the target must be running Google Chrome on Windows prior to 154.0.8037.92. The victim must then load attacker-controlled HTML that exercises the Media component (UI:R). High attack complexity (AC:H) reflects the timing/heap-state conditions to read the uninitialized resource. The impact is limited to a low-confidentiality memory read across the sandbox boundary (no integrity or availability impact), so this is realistically an exploit-chain building block rather than a self-contained attack.

This is a genuinely low-priority issue despite the 'Chromium security severity: High' label, and the signals are consistent once read carefully. The NVD CVSS 3.1 base score is 3.4 (AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:N/A:N): network vector but high attack complexity, no impact beyond a low-confidentiality memory read (I:N/A:N). The critical gating factor is embedded in the description, not the vector: exploitation requires an attacker 'who had compromised the renderer process' - i.e. this is a post-compromise sandbox-boundary information leak, not a standalone drive-by. The Chromium 'High' rating reflects that any sandbox-escape primitive is serious in a defense-in-depth model, but the standalone real-world impact is a small memory disclosure that presupposes the attacker already controls the renderer. No EPSS score, no CISA KEV listing, and no public exploit code are provided, so exploitation status is: no public exploit identified at time of analysis. There is no SSVC decision data in the input. Note the apparent tension worth flagging: the vector states PR:N (unauthenticated) yet the description requires a pre-compromised renderer - Chromium convention scores renderer-relative sandbox bugs as PR:N/UI:R, but defenders should treat 'compromised renderer' as a real precondition that substantially raises the practical bar. Net: real but low-priority hardening fix, not an urgent-patch emergency in isolation.

An attacker who has already gained code execution inside the Chrome renderer sandbox (e.g. via a separate, chained renderer bug) lures the victim to a page that drives the Media component to allocate and read an uninitialized resource. The uninitialized memory is then read back across the sandbox boundary, leaking small fragments of out-of-sandbox process memory that may aid further exploitation. No public proof-of-concept is provided, and the high attack complexity plus required prior renderer compromise make opportunistic mass exploitation impractical.