Google Chrome EUVD-2026-35222

Two stacked prerequisites are required. First, the attacker must have already compromised the renderer process - this is an explicit condition stated in the CVE description and is the primary limiting factor; it implies a separate prior exploit (e.g., a renderer RCE) must already have succeeded. Second, user interaction is required (UI:R from CVSS): the victim must visit an attacker-controlled or attacker-influenced HTML page containing crafted video content. The vulnerability is Windows-platform-specific; Chrome on macOS and Linux are not affected. High attack complexity (AC:H) reflects the combined weight of these prerequisites. Exploitation is bounded to confidentiality loss (no code execution, no data modification, no availability impact from this CVE alone). No authentication is required at the network level (PR:N), but the renderer-compromise prerequisite effectively imposes an equivalent technical barrier.

The CVSS 5.3 score (AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N) accurately reflects a moderate-priority issue constrained by significant real-world barriers. AC:H signals that the attack requires conditions beyond basic network access - specifically a pre-compromised renderer - which is a non-trivial prerequisite. UI:R means a victim must also visit a crafted page. The C:H confidentiality impact is meaningful but scoped (S:U, no sandbox escape), and there is no integrity or availability impact. No CISA KEV listing and no POC code are reported, meaning this is not known to be under active exploitation at time of analysis. EPSS data was not provided in the source intelligence, so probability-based prioritization cannot be quantified here. Practically, this vulnerability is most relevant as a component in a multi-stage exploit chain - an attacker with a renderer RCE uses this leak to extract heap layout or in-memory secrets (e.g., to defeat ASLR) before attempting a subsequent privilege escalation. Standalone exploitation for direct impact is not possible. Organizations running Chrome on Windows in high-value environments (sensitive data, privileged users) should prioritize patching given the potential chain value, but this is not a standalone emergency.

An attacker who has separately achieved renderer process compromise - for example via an unpatched renderer RCE - serves a crafted HTML page containing malicious video content to a Windows target. The Video component reads from uninitialized memory, and the attacker extracts the resulting data to recover heap addresses, stack canaries, or in-memory secrets, using that information to defeat ASLR or locate sensitive data before chaining to a privilege escalation. No public proof-of-concept code is known at time of analysis.