Google Chrome CVE-2026-11294

Exploitation requires the victim to visit a crafted HTML page in an affected version of Chrome (prior to 149.0.7827.53), confirmed by the UI:R component of the CVSS vector. The vulnerability is specific to Chrome's Passwords component - implying some interaction with password-related functionality (e.g., a login form or credential prompt) is likely required to trigger the spoofing behavior, though the exact triggering configuration is not publicly detailed beyond the crafted page requirement. No attacker authentication is required (PR:N). Exploitation is limited by: (1) mandatory user interaction - passive browsing alone is insufficient; (2) scope unchanged (S:U) - no OS-level escape is possible; (3) no confidentiality or availability impact - the attacker can only influence UI integrity; (4) the non-automatable SSVC rating, meaning mass exploitation at scale is not feasible. The 'Information Disclosure' metadata tag suggests indirect credential exposure is the realistic harm, not direct data exfiltration.

CVSS 4.3 (Medium-Low) with vector AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N reflects a vulnerability that is network-reachable at low complexity and requires no attacker privileges, but is gated by required user interaction (UI:R) - the victim must navigate to a malicious page. EPSS of 0.03% at the 11th percentile is extremely low, indicating that the broader security community observes negligible exploitation activity. SSVC confirms: Exploitation status is 'none,' the attack is not automatable (consistent with UI:R), and technical impact is only partial. There is no KEV listing and no POC code identified. Taken together, these signals consistently indicate a low real-world priority: the CVSS score is already modest, and all corroborating signals (EPSS, SSVC, KEV absence) reinforce a below-average exploitation risk. The 'Information Disclosure' tag in the metadata is somewhat inconsistent with the CVSS C:N rating - this may reflect potential for indirect credential exposure through UI deception rather than direct data leakage, but this is inferred and not explicitly confirmed by vendor documentation.

An attacker crafts an HTML page that triggers Chrome's Passwords component to render a spoofed UI element - for example, a fake 'Save Password' dialog or a mimicked autofill prompt - that visually impersonates a legitimate Chrome credential UI. A victim browsing to this page (e.g., via a phishing link) could be deceived into interacting with the spoofed element, potentially submitting credentials to an attacker-controlled context or dismissing a legitimate security prompt. No public POC exists, so exploitation requires independent discovery of the triggering mechanism.