Google Chrome EUVD-2026-89235

Exploitation requires the victim to actively browse to attacker-controlled web content using a vulnerable Chrome build (before 154.0.8037.57) - UI:R makes user interaction mandatory. The AC:H metric means the attacker must satisfy a non-trivial precondition such as precise heap grooming or a timing race to win the use-after-free reclamation, so exploitation is not reliably one-shot. No authentication and no special server-side configuration are needed (PR:N). The scope change (S:C) indicates a successful exploit crosses out of the renderer sandbox. Limiting factors: required user interaction, high attack complexity, and the availability of a vendor patch that removes the window once applied.

The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H, base 8.3) describes a network-reachable, unauthenticated CWE-416 use-after-free requiring user interaction (visiting a malicious page) and a high-complexity trigger, with a scope change (S:C) indicating a sandbox-escape-class outcome rather than renderer-only containment. All three impact metrics are High, consistent with memory-corruption leading to arbitrary code execution. No EPSS score, no CISA KEV listing, and no public exploit code are present in the input, so this is 'no public exploit identified at time of analysis' - a high-severity issue but not a confirmed active-exploitation priority. The AC:H metric is the main real-world limiter: unlike the AC:L UAF/heap siblings in this same Chrome batch, this bug needs specific heap grooming or timing, which lowers the practical exploitation likelihood relative to its 8.3 score. Chrome's ubiquity keeps this a HIGH patch-management priority despite the absence of exploitation signals. Note the tag set includes 'Information Disclosure' which is inconsistent with the I:H/A:H impact - this is a code-execution-class memory-corruption bug, not primarily a disclosure issue.

An attacker hosts a malicious web page and lures a Chrome user (before 154.0.8037.57) to visit it. The page drives the browser into a use-after-free condition and, through careful heap manipulation (reflecting the high attack complexity), reclaims the freed object to corrupt memory and achieve code execution that crosses the security boundary (S:C). No public proof-of-concept is identified at time of analysis.