Google Chrome CVE-2026-106406

Exploitation requires the victim to be running Google Chrome on iOS at a version prior to 155.0.8059.39, to be socially engineered into opening an attacker-crafted HTML page, and then to interact with or trust the spoofed UI element (UI:R). The attack is network-delivered and needs no authentication or prior privileges, but it cannot execute code or steal data on its own - its ceiling is deceiving the user via forged UI. Limiting factors: mandatory user interaction and the social-engineering dependence, restriction to the iOS Chrome build, and the already-available vendor patch that remediates updated clients.

This is a genuinely medium-tier, low-urgency issue rather than a high-priority emergency. The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:L, base 5.4) describes a network-reachable, unauthenticated flaw with low attack complexity, but exploitation is gated by required user interaction (UI:R) and, per the description, by social engineering - the attacker must convince a victim to open a crafted page and act on a spoofed UI element. There is no EPSS score, no CISA KEV listing, and no public exploit (POC) in the supplied data, so no signal points to active or imminent exploitation; the correct status is 'no public exploit identified at time of analysis.' Chromium rated the security severity Medium, consistent with a UI-spoofing/missing-authorization bug (CWE-862) rather than memory-corruption RCE. One inconsistency should be flagged: the supplied impact metrics (C:L/I:N/A:L) are a poor fit for a UI-spoofing defect, which normally manifests as an integrity impact (misleading the user) rather than availability loss - verify the official metrics with Google/NVD. Overall: patch in the normal Chrome auto-update cycle; this does not warrant out-of-band emergency response.

An attacker crafts a malicious HTML page and uses social engineering (phishing link, malicious ad, or messaging lure) to get an iOS Chrome user to open it. The page abuses the flaw to spoof browser UI elements - for example a faked address bar, security indicator, or permission prompt - so the victim trusts attacker-controlled content or is tricked into an action. No public exploit code is identified at time of analysis, and the attack cannot succeed without the victim's interaction.