Google Chrome EUVD-2026-93650

Exploitation requires that the attacker has ALREADY compromised the renderer process (a prior-stage exploit is a hard prerequisite per the description), plus user interaction - the victim must load the attacker's crafted HTML page (UI:R). The weakness is specific to Chrome's FontAccess feature and a use-after-release (CWE-672) condition within it. These factors substantially limit real-world risk: this is not a standalone remote entry point but a cross-origin boundary bypass usable only after an initial foothold, and it affects Chrome versions prior to 155.0.8059.39 on default desktop configurations.

This is a medium-severity, defense-in-depth issue rather than a top priority. The official CVSS is 6.5 (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N), but Chromium itself rated the security severity as Low, and the EPSS score is only 0.31% (22nd percentile), consistent with no observed exploitation interest. There is no CISA KEV listing and no public exploit identified at time of analysis, so this is 'no public exploit identified at time of analysis.' Critically, the CVSS vector and the description conflict on the true barrier to exploitation: the vector shows PR:N (no privileges), but the description explicitly states the attacker must have ALREADY compromised the renderer process - this is a second-stage sandbox/origin-boundary weakness, not a standalone remote entry point, so the PR:N rating understates the real prerequisite and the AC:L rating is arguably too low. The SSVC framework is not provided in the input. Net assessment: real but low operational priority - it is only reachable after an attacker already holds a foothold in the renderer, and it yields origin-policy bypass rather than code execution; verify the chaining prerequisite against Google's advisory.

An attacker who has already exploited a separate renderer bug (e.g., via a malicious or compromised web page the victim visits) leverages a use-after-release condition in Chrome's FontAccess implementation to bypass the same-origin/web-origin policy. By serving a crafted HTML page, the attacker manipulates a released FontAccess resource to access or affect data belonging to another web origin. No public proof-of-concept is identified at time of analysis, and the attack requires a pre-existing renderer compromise plus user interaction (visiting the page).