Google Chrome EUVD-2026-89404

Exploitation requires the victim to visit an attacker-crafted HTML page in Google Chrome on iOS (versions prior to 154.0.8037.92) and to interact with the spoofed SignIn UI (UI:R). No authentication or special privileges are needed (PR:N), and no non-default configuration is required, but the platform is limited to iOS builds of Chrome and the impact is confined to UI misrepresentation - the attacker cannot execute code or corrupt memory, only deceive the user into trusting spoofed interface elements.

This is a low-priority issue despite a moderate CVSS 5.4. The CVSS vector (AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:L) shows a network-reachable, low-complexity, unauthenticated flaw, but it requires user interaction (UI:R) and delivers only low, non-scope-changing impact - consistent with Chromium's own 'Low' security-severity rating. All exploitation signals point the same way: SSVC records Exploitation=none, Automatable=no, and Technical Impact=partial, meaning CISA's framework sees no observed exploitation and no reliable automation. There is no CISA KEV listing, no EPSS score supplied, and no public exploit identified at time of analysis. The A:L (availability) metric in the vendor vector is questionable for a pure UI-spoofing/misrepresentation bug (CWE-451), which typically has no genuine availability impact; verify with vendor. No signals conflict in a way that would elevate this - CVSS, SSVC, and the Chromium 'Low' label all agree this is a minor spoofing weakness rather than a memory-corruption or RCE-class flaw.

An attacker hosts a crafted HTML page and lures an iOS Chrome user to visit it; the page manipulates the rendering of the browser's SignIn UI so spoofed elements (e.g. a fake sign-in prompt) appear legitimate, tricking the victim into trusting attacker-controlled content or divulging credentials. No public exploit code is identified, and success depends on the victim interacting with the spoofed interface.