Google Chrome EUVD-2026-34716

The attacker must have already compromised the Chrome renderer process - this is an explicit precondition stated in the CVE description, not a generic assumption, and effectively requires a separate renderer-side bug (memory corruption or logic flaw) as the entry vector. The victim must then load a crafted HTML page in the affected Chrome build (any desktop version prior to 149.0.7827.53), and the targeted cross-origin data must be accessible via Storage Access API code paths. Limiting factors: Chrome's auto-update mechanism rapidly shrinks the vulnerable population, the requirement for a prior renderer compromise gates this to attackers with an exploit chain or a second N-day, and the impact is confidentiality-only (no integrity or availability impact per the CVSS vector).

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) produces a base score of 7.5 driven entirely by high confidentiality impact with no privileges or user interaction, but this score conflicts with the real-world preconditions: the description explicitly requires that the attacker has already compromised the renderer process, which is a non-trivial prerequisite that PR:N does not capture. Google's own Chromium severity rating of Low aligns more closely with reality, reflecting that this is a sandbox-relevant info-leak useful only as a second-stage primitive in a chain. There is no public exploit identified at time of analysis, the CVE is not listed in CISA KEV, and no EPSS score was supplied; Chrome bugs of this class rarely see opportunistic mass exploitation but are routinely chained by sophisticated actors targeting browsers. Net assessment: patch promptly as part of normal Chrome update cadence, but it is not an emergency comparable to a one-shot RCE in the renderer.

An attacker first lures a victim to an attacker-controlled page that exploits a separate renderer-compromise bug (e.g., a V8 type-confusion or Blink use-after-free) to gain code execution inside the sandboxed renderer process. From there, the malicious renderer abuses the Storage Access API's insufficient input validation via a crafted HTML payload to read cross-origin data - such as authenticated session data tied to another site the user is logged into - and exfiltrates it back to the attacker. No public exploit has been identified at the time of analysis, so this is a hypothetical chaining scenario consistent with the CVE description.