Chrome for iOS CVE-2026-13905

Physical access to the target iOS device is the absolute prerequisite (AV:P); remote or network exploitation is not possible for this vulnerability. High attack complexity (AC:H) means the attacker must successfully win a race condition, requiring precise timing during a concurrent Chrome operation - this is not reliably repeatable without repeated attempts or specialized tooling. The device must be running Google Chrome for iOS in a version prior to 150.0.7871.47. No authentication is required per CVSS (PR:N), meaning the attacker need not be logged into the device or Chrome account - physical presence alone is the gate. Exploitation is further constrained by iOS's process sandbox, which limits the blast radius of memory disclosure to Chrome's own process space. There is no indication that a non-default configuration is required; any standard Chrome for iOS installation in the affected version range is potentially vulnerable if physically accessible.

The CVSS 3.1 base score of 4.2 with vector AV:P/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N accurately reflects a constrained threat profile: physical device access (AV:P) is the binding prerequisite, and high attack complexity (AC:H) means the attacker must reliably trigger and win a timing race - not a trivial task. Despite the C:H impact rating, the combination of physical access and race-condition timing reduces the realistic attacker population to highly targeted scenarios such as device seizure, unattended device opportunism, or forensic-style access. No EPSS score was provided in the input data, and the vulnerability does not appear in CISA KEV, indicating no confirmed widespread exploitation. No public proof-of-concept has been identified. This is not a prioritization concern for most enterprise security teams under standard threat models, but it warrants attention for organizations protecting high-value individuals (executives, journalists, government personnel) whose devices may be subject to physical inspection or confiscation.

An attacker who gains brief physical access to an iOS device - for example, while the device is unattended or during a border inspection - opens Chrome and triggers a specific concurrent operation to create the race condition window. By precisely timing interaction with Chrome's internal shared memory state during that window, the attacker reads process memory contents that may include cached credentials, browsing session data, or other sensitive in-memory artifacts. No public proof-of-concept has been identified, making successful exploitation dependent on attacker-developed tooling and precise device timing.