Google Chrome EUVD-2026-93743

Exploitation requires that the attacker has ALREADY compromised Chrome's renderer process (per the description, 'a remote attacker who had compromised the renderer process') - this is a secondary, post-exploitation primitive, not a standalone remote vulnerability. The attacker must then deliver a crafted HTML page and the victim must view/interact with it (CVSS UI:R). Exploitation targets the Compositing component on Chrome versions prior to 155.0.8059.39. Limiting factors: high attack complexity (AC:H), mandatory user interaction, the prerequisite of a working renderer-compromise exploit chain, and impact bounded to address-bar spoofing (no direct code execution or data exfiltration from this flaw alone). These conditions make realistic standalone exploitation improbable.

This is a genuinely low-priority issue despite being network-reachable. The CVSS 3.1 base score of 4.2 (Medium) aligns with Chromium's own 'Medium' severity rating, and the vector (AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:L) reflects meaningful barriers: high attack complexity and required user interaction. The single most important risk-limiting signal is in the description, not the CVSS vector: exploitation requires 'a remote attacker who had compromised the renderer process' - i.e. this is a post-exploitation sandbox/UI primitive, not a standalone entry point. The CVSS vector encodes PR:N, which conflicts with the description's precondition of a pre-compromised renderer; this is standard Chromium scoring practice (the renderer compromise is treated as an attack precondition rather than a privilege), but defenders should read PR:N here as 'no additional privilege beyond an already-compromised renderer,' NOT as trivially unauthenticated. No EPSS score was provided in the input, so exploitation probability cannot be quantified. The CVE is NOT listed in CISA KEV and no proof-of-concept is referenced, so there is no public exploit identified at time of analysis. No SSVC decision data was supplied. Net: a low-impact (address-bar spoof only) secondary vulnerability requiring an already-compromised renderer plus user interaction - real but low real-world risk, appropriately patched in a routine stable-channel update.

An attacker who has already achieved code execution inside Chrome's renderer process (e.g. via a separate RCE bug) lures the user to a crafted HTML page that abuses the compositing input-validation flaw to render a misleading URL in the address bar. The user, trusting the spoofed address bar, is more readily phished for credentials or deceived about the true origin of content. No public exploit code is identified at time of analysis, and the high attack complexity plus required renderer pre-compromise make opportunistic use unlikely.