Google Chrome CVE-2026-110158

Exploitation requires a specific precondition stated in the description: the attacker must have ALREADY compromised the Chrome renderer process (i.e., this is a sandbox-escape stage in a multi-step exploit chain, not a standalone attack). Beyond that, it requires user interaction (UI:R) - the victim must load a crafted HTML page - and the flaw carries high attack complexity (AC:H), implying the use-after-free in the Passwords component must be reliably won under specific timing/heap conditions. The limiting factors that reduce real-world risk: the need for a separate prior renderer compromise, the victim navigation requirement, high exploitation complexity, and the fact that a vendor fix (155.0.8059.79) is already available. These conditions make opportunistic mass exploitation unlikely and favor targeted use.

This is a genuinely serious but conditionally-gated vulnerability, and the signals are internally consistent rather than conflicting. The provided CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H, base 8.3) reflects a network-reachable flaw with high attack complexity, requiring user interaction and producing total impact with a scope change - consistent with a sandbox escape (code execution outside the Chrome sandbox). However, the description imposes a critical precondition that CVSS PR:N does not capture: the attacker must ALREADY have compromised the renderer process, meaning this is a second-stage exploit in a chain, not a standalone one-click compromise. The exploitation signals argue strongly AGAINST treating this as an emergency: there is no CISA KEV listing, and CISA's SSVC decision framework explicitly records Exploitation=none and Automatable=no (with Technical Impact=total). No public exploit code is referenced in the input. The EPSS score was not provided, so probabilistic exploitation likelihood cannot be factored in - STATE EXPLICITLY: EPSS data is missing from this input. Net assessment: a high-severity memory-corruption bug (CWE-416 use-after-free) in a ubiquitous product with a vendor patch already available, but one whose real-world risk is tempered by the need for a prior renderer compromise, high attack complexity, and user interaction. Priority is 'patch promptly in normal cycle' rather than 'drop everything,' given no evidence of active or automatable exploitation.

An attacker who has already exploited a separate renderer-process vulnerability lures a victim to a crafted HTML page, which triggers a use-after-free in Chrome's Passwords component to break out of the renderer sandbox and execute arbitrary code at the browser-process privilege level. No public exploit code is identified in the provided data, and the high attack complexity (AC:H) plus the requirement for a pre-compromised renderer make this a chained, targeted scenario rather than a drive-by compromise.