Google Chrome iOS CVE-2026-13809

Exploitation requires that the attacker has already compromised the Chrome renderer process on the victim's iOS device - this is an explicit, non-trivial precondition stated in the CVE description and reflected in the SSVC 'automatable: no' rating. The victim must additionally navigate to or be directed to a crafted HTML page (UI:R per CVSS), meaning passive exploitation without user interaction is not possible. The vulnerability is limited to Chrome on iOS specifically; desktop Chrome and Safari are not listed as affected. Limiting factors: (1) renderer compromise as a hard prerequisite severely restricts the attacker population; (2) user interaction required for page visit; (3) iOS platform restriction; (4) impact is read-only confidentiality (cross-origin data leak) with no integrity or availability impact.

The CVSS 3.1 score of 6.5 Medium reflects the network attack vector and high confidentiality impact but does not fully capture the real-world exploitation barrier: a compromised renderer process is a hard prerequisite. The official vector (AV:N/AC:L/PR:N/UI:R) rates complexity as Low, which appears to understate the requirement for prior renderer compromise - an independent, non-trivial precondition. SSVC corroborates low urgency: exploitation is rated 'none', automatable is 'no', and technical impact is only 'partial'. EPSS at 0.21% (11th percentile) further confirms this is unlikely to see broad exploitation. The vulnerability is not in CISA KEV. The net assessment is that this is a real but low-priority issue: meaningful only in the context of a chained attack where an adversary has already achieved renderer compromise, making this a post-exploitation data-exfiltration primitive rather than an initial access vector.

An attacker who has already exploited a separate vulnerability to achieve renderer process compromise in Chrome on iOS then directs the victim to a crafted HTML page; the page triggers Safe Browsing evaluation in a way that produces observable side-channel signals (e.g., timing differences in resource loading or state transitions) which the compromised renderer reads to infer cross-origin content the attacker would otherwise be barred from accessing. No public proof-of-concept exploit code has been identified at time of analysis, so this scenario remains theoretical for opportunistic attackers.