Google Chrome CVE-2026-17920

Exploitation requires the attacker to first convince the victim to install a specific malicious Chrome extension (the crafted extension is the exploit delivery vehicle) and then have that extension execute in the browser - this is the UI:R user-interaction requirement made concrete. What limits exploitation: the victim must actively install attacker-supplied extension code (a significant social-engineering hurdle, and a policy hurdle in managed environments); the vulnerable Chrome build must be below 151.0.7922.72; and the payload runs only inside the renderer sandbox, so absent a separate sandbox-escape chain the attacker does not gain host-level code execution. There is no unauthenticated drive-by path here despite PR:N - the foothold comes from the user installing the extension, not from any web page.

The signals conflict and must be weighed. The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H = 8.8) reflects Google's standard scoring for renderer RCE, but Chromium itself rated this 'Low' security severity and EPSS agrees at 0.13% (3rd percentile). The gating factor is UI:R combined with the description's requirement that the attacker first convince the user to install a malicious extension - a high social-engineering barrier and far more constrained than a drive-by web-page exploit. Impact is further limited because code runs inside the sandbox with no accompanying escape reported (S:U). There is no KEV listing and no public exploit identified at time of analysis. Net: a real memory-safety bug worth patching in the normal browser update cycle, not an emergency; the raw 8.8 overstates real-world urgency for a bug that requires a user to install hostile code and yields only in-sandbox execution.

An attacker publishes or side-loads a Chrome extension whose bundled JavaScript is crafted to trigger the V8 use-after-free, then lures a target (via a fake productivity tool, phishing page, or compromised extension update) into installing it. Once installed and run, the extension corrupts V8 heap memory to execute arbitrary code inside the renderer sandbox, where it can access the browsing context and page data available to that process. No public exploit identified at time of analysis, and the AV:N/AC:L profile makes the memory-corruption step reliable once the user is convinced to install.