Google Chrome EUVD-2026-93826

Exploitation requires the attacker to have ALREADY compromised Chrome's sandboxed renderer process (typically via a separate renderer vulnerability) before this use-after-free in the Storage component can be leveraged to escape the sandbox; it is therefore a second-stage/chaining primitive rather than an initial-access flaw. The victim must also load an attacker-controlled crafted HTML page (UI:R), and high attack complexity (AC:H) applies due to the memory-grooming needed to exploit a use-after-free reliably. Affects Chrome versions prior to 155.0.8059.39 across default configurations; the primary limiting factors are the mandatory prior renderer compromise, required user interaction, and non-trivial exploitation reliability.

Signals point to a genuine but second-stage threat rather than a standalone mass-exploitation risk. The CVSS 3.1 base score of 8.3 (AV:N/AC:H/PR:N/UI:R/S:C) is elevated primarily by the scope change (S:C) reflecting a sandbox escape and full C:H/I:H/A:H impact, tempered by high attack complexity (AC:H) and required user interaction (UI:R). Critically, the description states the attacker must have ALREADY compromised the renderer process, so despite PR:N in the vector this is a chaining/escape primitive, not a single-shot remote compromise - the PR:N reflects Chrome's convention of scoring from the web-content privilege level, which partially conflicts with the real-world prerequisite of a prior renderer bug. CISA SSVC reinforces lower urgency: Exploitation=none (no observed or public exploitation), Automatable=no (consistent with AC:H and the need for a chained renderer compromise), though Technical Impact=total aligns with the memory-corruption RCE outcome. There is no CISA KEV listing and no EPSS score was supplied, and no public POC is referenced. Net: a real and worthwhile patch priority because of the ubiquity of Chrome and the total technical impact, but not an emergency single-bug RCE - realistic exploitation requires pairing with a separate renderer exploit, which is why automatability and observed exploitation are both low/none.

An attacker who has already achieved code execution inside Chrome's sandboxed renderer (via a separate vulnerability) lures or redirects the victim to a crafted HTML page that triggers a use-after-free in the Storage component. By grooming the freed object, the attacker escapes the sandbox and executes arbitrary code with the browser process's privileges on the host. No public exploit code is identified at time of analysis, and high attack complexity makes reliable exploitation non-trivial.