Google Chrome EUVD-2026-93599

Exploitation requires the attacker to have ALREADY compromised Chrome's sandboxed renderer process (per the description) - this is the dominant limiting factor and means the flaw is only reachable as a chained post-exploitation step, not independently. Additionally, user interaction is required (UI:R - the victim must load the attacker's crafted HTML page), and attack complexity is high (AC:H). Impact is confined to spoofing UI elements in the Permissions surface; it does not grant code execution, data exfiltration beyond low confidentiality, or sandbox escape on its own. The affected versions are Chrome builds prior to 155.0.8059.39; patched builds are not vulnerable.

This is a low-priority issue despite being network-reachable. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:L, base 4.2) and Chrome's own 'Low' severity rating are consistent with each other and with the SSVC decision (Exploitation: none, Automatable: no, Technical Impact: partial). The single most important signal is in the description, not the vector: exploitation requires an attacker who has ALREADY compromised the renderer process. That precondition is a far stronger gate than the CVSS vector conveys - PR:N is used here because Chromium models the renderer as the entry point, but in practical terms the attacker must first chain a separate renderer-compromise bug, so this is a post-exploitation UI-spoofing primitive rather than a standalone remote attack. No EPSS score was provided, there is no CISA KEV listing, and no public exploit is identified; SSVC explicitly rates exploitation as 'none'. The impact is limited to UI spoofing (C:L, I:N, A:L), not code execution or data theft. Net assessment: real but minor - patch in the normal Chrome auto-update cycle, not an emergency.

An attacker who has already gained code execution inside Chrome's sandboxed renderer process (via a separate, unpatched bug) loads a crafted HTML page that abuses the missing authorization check in the Permissions component to render deceptive or spoofed UI elements (e.g., misleading permission or security indicators), potentially tricking the user. Given AC:H and the renderer-compromise prerequisite, this is a chained post-exploitation technique, not a one-shot drive-by. No public exploit code is identified at time of analysis.