Google Chrome EUVD-2026-93638

Exploitation requires that the attacker has ALREADY compromised the Chrome renderer process (a separate prior vulnerability), after which a crafted HTML page is used to win a time-of-check/time-of-use race (CWE-367) in the browser process to spoof UI elements. Limiting factors: the renderer-compromise prerequisite means this is a post-compromise secondary primitive rather than a standalone remote attack; high attack complexity (AC:H) reflects the non-deterministic timing window of the race; user interaction is required (UI:R) since the victim must view and act on the spoofed interface; and only versions prior to 155.0.8059.39 on Google Chrome (desktop) are affected. Despite CVSS PR:N, the practical barrier of needing a compromised renderer substantially constrains real-world exploitation.

Multiple signals converge on this being a genuinely LOW priority. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:L, base 4.2) combines high attack complexity with required user interaction, and Chromium itself rated the security severity 'Low'. The CISA SSVC framework reinforces this: Exploitation=none (no observed activity), Automatable=no, Technical Impact=partial. KEV status is NO and no POC is referenced, so this is no public exploit identified at time of analysis - not active exploitation. A key nuance limits real-world risk well below what AV:N/PR:N alone would suggest: the description states the attacker must ALREADY have compromised the renderer process, making this a sandbox-escape-adjacent, post-compromise UI-spoofing primitive rather than a standalone remote entry point. The CVSS PR:N (unauthenticated) therefore understates the practical precondition - verify the renderer-compromise prerequisite against the Chromium bug tracker before treating it as pre-auth. MISSING DATA: no EPSS score was provided, so exploitation-probability cannot be quantified; however KEV=none, SSVC Exploitation=none and the narrow impact (UI spoofing, no code execution) all point to very low urgency. The 'Information Disclosure' tag also conflicts with the described impact, which is UI spoofing (an integrity/deception issue), not data disclosure.

An attacker who has already exploited a separate flaw to compromise Chrome's renderer process serves a crafted HTML page that wins a timing race in the browser process, causing security-relevant UI elements (e.g. address bar, dialogs, or permission prompts) to be rendered deceptively. The victim, trusting the spoofed chrome, is lured into a phishing or consent action. No public exploit code is identified at time of analysis, and high attack complexity plus the required renderer-compromise precondition make reliable exploitation difficult.