Chrome for iOS EUVD-2026-50738

The attacker must be capable of delivering malicious network traffic to the victim's iOS device - implying a network-adjacent position such as a rogue access point, DNS hijack, or man-in-the-middle interception, or the ability to serve crafted HTTP responses via a network path the victim traverses. User interaction is required per the CVSS UI:R metric; the victim must perform a browser action in Chrome for iOS that triggers the navigation path containing the validation flaw. The vulnerability is specific to Chrome running on iOS; desktop and Android Chrome are not identified as affected. No attacker authentication or privileges are required. Exploitation is bounded by the requirement for both network traffic control and victim interaction, excluding purely passive or fully remote-no-interaction attack models.

The CVSS 3.1 vector AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N scores 6.5 (Medium), reflecting network-reachable exploitation with no authentication required but mandatory user interaction - the victim must perform a browser action such as clicking a link or loading a page while exposed to malicious traffic. The Integrity:High rating captures the ability to bypass navigation restrictions, which could enable phishing redirects, frame injection, or security policy circumvention. Confidentiality and Availability are unaffected per the vector. EPSS at 0.17% (7th percentile) signals very low exploitation probability relative to the broader CVE landscape, and the absence of a CISA KEV entry confirms no known active exploitation at time of analysis. No public proof-of-concept has been identified. The practical risk is moderate in targeted scenarios - particularly MITM attacks against iOS Chrome users on untrusted networks - but mass exploitation is constrained by the user-interaction requirement and narrow iOS platform scope. Organizations managing corporate iOS fleets should treat this as a standard patch-cycle priority rather than an emergency.

An attacker positioned as a network intermediary - such as operating a rogue Wi-Fi access point in a public location - serves crafted HTTP responses to an iOS device running a vulnerable version of Chrome, exploiting the insufficient input validation to bypass the browser's navigation restriction logic. The victim must interact with Chrome while connected to the attacker-controlled network, such as navigating to a page or following a link, at which point the malicious traffic triggers the bypass and the attacker can redirect the browser to an attacker-controlled destination outside enforced security boundaries. No public proof-of-concept is available at time of analysis.