Google Chrome CVE-2026-11674

Victim must browse with a vulnerable Chrome desktop build (prior to 149.0.7827.103) to attacker-controlled HTML content that exercises the Guest View code path - typically content involving <webview>, MimeHandlerView, or other guest frame embeddings. User interaction is required (UI:R): the victim must navigate to or be redirected to the malicious page; no authentication is needed (PR:N). Exploitation is LIMITED by Chrome's renderer sandbox - code execution is confined to the sandboxed renderer process (S:U), so achieving host compromise additionally requires a chained sandbox-escape vulnerability. Chrome's silent auto-update further limits the exposure window for most consumer installations.

The CVSS 8.8 reflects network-reachable, low-complexity exploitation with no privileges required but requiring user interaction (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H), which is consistent with a drive-by browser bug. There is no CISA KEV listing and no public POC referenced in the available intelligence, and EPSS data was not supplied; Chrome UAFs are historically high-value targets for exploit chains but most never see widespread untargeted abuse before patches roll out via Chrome's auto-update channel. A critical caveat: the Scope is Unchanged (S:U) and the description explicitly states code execution occurs 'inside a sandbox' - meaning this is NOT a one-shot host RCE, and an attacker would need to chain a separate sandbox-escape bug to achieve meaningful impact outside the renderer, which materially lowers real-world risk compared to the raw CVSS number. Prioritize patching for high-risk user populations (executives, developers, journalists) but treat as routine Chrome update for general fleets.

An attacker hosts or compromises a website serving a crafted HTML page that triggers the use-after-free in Guest View, then drives traffic to it via phishing, malvertising, or watering-hole on a forum the target frequents. When a victim running a vulnerable Chrome build loads the page, the dangling pointer is dereferenced to gain code execution inside the renderer sandbox; a real-world attack chain would pair this with a separate sandbox-escape vulnerability to fully compromise the host. No public exploit code has been identified at time of analysis.