Google Chrome EUVD-2026-35248

Victim must be running Chrome on Windows at a version below 149.0.7827.103 and must visit (or be redirected to) attacker-controlled HTML content - UI:R in the CVSS vector confirms user interaction is required, typically a navigation or click. No authentication or pre-existing privileges on the target are needed (PR:N). Exploitation is limited to the renderer process boundary (S:U) unless chained with a separate sandbox-escape vulnerability, and is platform-limited to Windows per the description; macOS and Linux Chrome builds are not listed as affected in the provided data. Hardened configurations that disable the Fullscreen API or block untrusted origins via enterprise policy further reduce reachability.

Signals are mixed but lean toward prioritized patching: CVSS 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) indicates remote, unauthenticated, low-complexity exploitation requiring a single user click/navigation, with high impact on confidentiality, integrity, and availability within the renderer's scope. The scope is Unchanged (S:U), meaning initial compromise stays within the renderer sandbox absent a chained sandbox escape - a meaningful tempering factor for browser UAFs. There is no public exploit identified at time of analysis and no CISA KEV listing, and EPSS data was not provided. Chromium's own High severity rating and Google's prompt stable-channel push align with treating this as a real but not emergency priority; it warrants the normal Chrome auto-update cycle within days, not weeks. No conflicting signals were observed in the provided data, but absence of EPSS and KEV inputs means real-world exploitation likelihood is inferred from class history (browser UAFs are frequently weaponized) rather than confirmed.

An attacker hosts a malicious HTML page that scripts an abusive Fullscreen API interaction sequence to trigger the use-after-free in Chrome's FullScreen code path. The victim is lured via phishing, malvertising, or a watering-hole compromise and clicks/navigates to the page, satisfying the UI:R requirement; the dangling pointer is dereferenced over attacker-controlled heap state, yielding renderer-process memory corruption that can be shaped into code execution within the sandbox. No public exploit has been identified at time of analysis, but UAFs in Blink-adjacent UI code have historically been chained with sandbox escapes for full host compromise.