Google Chrome CVE-2026-17809

Exploitation requires two mandatory preconditions: (1) the attacker must have already achieved code execution within the Chrome renderer process - typically via a separate, unrelated browser vulnerability (this is the primary complexity barrier captured by CVSS AC:H); and (2) the victim must visit an attacker-controlled or compromised web page that delivers the crafted HTML payload (UI:R). The Chrome Extensions subsystem must be reachable from the renderer, which is true in default Chrome configurations. Exploitation is specifically limited to: Chrome versions prior to 151.0.7922.72; environments where browser extensions are not fully disabled via enterprise policy; and targets who can be socially engineered or redirected to visit a malicious page while a renderer-level exploit is active. Fully disabling extensions via enterprise policy removes the vulnerable code path. There is no authentication or privilege barrier for the attacker themselves (PR:N), but the renderer pre-compromise is a non-trivial technical prerequisite that substantially limits the attacker population.

The CVSS 3.1 vector AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:L yields a 5.8 base score that understates operational risk. AC:H correctly captures the mandatory renderer pre-compromise prerequisite, and S:C flags that impact escapes the sandbox to the host system. Despite individually low C/I/A ratings, a successful sandbox escape translates to arbitrary code execution at OS level when the chain is complete, making the effective real-world severity significantly higher than the numeric score suggests. EPSS at 0.17% (7th percentile) aligns with no observed mass exploitation; no KEV listing confirms this is not currently being actively exploited at scale. No public POC has been identified. The SSVC signals point to a 'track' or 'attend' posture for most organizations: exploitation is technically complex (chained attack), not yet automated, and requires user interaction. However, threat actors with renderer-RCE capability - as seen in prior Chrome exploit chains - would find this a high-value second-stage primitive. Priority should be elevated for high-value targets (journalists, executives, government users) where targeted exploitation is plausible.

A threat actor first exploits a separate memory corruption or type confusion vulnerability in Chrome's renderer to gain sandboxed code execution - for example, through a malicious web page embedding a renderer-targeting exploit. From within the compromised renderer, the attacker crafts input targeting the Extensions component's insufficient validation boundary and triggers the CWE-20 flaw to break out of Chrome's sandbox, landing code execution at the host OS process level. No public POC has been identified; real-world use of this chain has not been confirmed by CISA KEV or vendor incident reports.