CVE-2026-13887: Cross-Origin Data Leak in Chrome NFC on Android

Technical summary

CVE-2026-13887 is an origin-isolation bypass in the NFC (Near Field Communication) implementation of Chromium's rendering engine on Android. The vulnerability stems from inappropriate handling of cross-origin requests within the renderer process, allowing a post-compromise attacker to exfiltrate sensitive data via crafted HTML. The issue is rooted in improper implementation of origin-based access controls (CWE-346) and cross-site request forgery (CSRF) protections (CWE-352). Exploitation requires renderer process compromise as a prerequisite condition, making this a secondary exploit chain component rather than a direct entry vector.

Business impact

Organizations deploying Chrome on Android devices face data exfiltration risk if renderer processes are compromised through other attack vectors. While not directly exploitable from the network alone, this vulnerability becomes material in defense-in-depth scenarios where initial compromise has occurred. The impact is confidentiality-focused: sensitive user data, authentication tokens, or personal information accessible within the browser context may leak to attacker-controlled infrastructure. For enterprises managing BYOD or company-issued Android devices, this represents an additional risk layer requiring patching discipline.

Affected systems

Google Chrome on Android operating system, versions prior to 150.0.7871.47. The vulnerability does not affect Chrome on other platforms (Windows, macOS, Linux, iOS). Android users on older Chrome builds remain exposed until they update through Google Play Store or Samsung Internet (which ships Chromium). Devices locked to older Android OS versions that do not receive Chrome updates face extended exposure.

Exploitability

Practical exploitation requires two conditions: (1) the renderer process must already be compromised through a separate vulnerability or attack, and (2) the user must visit a crafted malicious webpage. This two-stage requirement significantly raises the attack difficulty compared to a direct remote code execution. The CVSS vector reflects this: no network-only path exists (AV:N describes the second stage; the first stage is out-of-band). Exploit development and weaponization are non-trivial, and this is not currently tracked in CISA's KEV catalog, indicating no observed active exploitation in the wild as of the publication date.

Remediation

Update Google Chrome on Android to version 150.0.7871.47 or later. Users can check their current version via Settings > About Chrome, which will auto-prompt for updates if available. Enterprise administrators managing Chrome on Android via Mobile Device Management (MDM) should deploy version 150.0.7871.47 or newer through their management console. For devices unable to receive the patched version due to OS constraints, implement application-level controls: restrict browsing to trusted sites, disable NFC if not required, and enforce browser sandboxing features where available.

Patch guidance

Google released the patch in Chrome 150.0.7871.47 for Android. Verify patch deployment by confirming the version string in Chrome Settings > About Chrome; the browser will auto-update on most Android devices via Google Play Store when the patch is available. IT administrators should test the update in a staging environment before broad deployment, particularly for mission-critical applications relying on Chrome on Android. No special configuration is required post-patch; the fix is transparent to end users.

Detection guidance

Detection of active exploitation is challenging without endpoint detection and response (EDR) tools capable of monitoring renderer process behavior. Look for: (1) unexpected child process spawning from Chrome (renderer crashes followed by respawns may indicate fuzzing or exploitation attempts), (2) unusual network exfiltration patterns coinciding with browser activity, (3) large data transfers to unfamiliar IP addresses during NFC-adjacent operations. Log aggregation from Android MDM solutions should flag devices running Chrome versions below 150.0.7871.47. Network-level detection is limited, as the data exfiltration occurs within an already-compromised renderer and may blend with normal HTTPS traffic.

Why prioritize this

This vulnerability ranks as medium priority for most organizations due to its two-stage exploitation requirement: it is not a direct entry vector but rather a post-compromise data leakage risk. Prioritization should be elevated for organizations with high-risk BYOD programs, those managing sensitive financial or healthcare data on mobile devices, or those facing advanced persistent threat (APT) actors known to exploit Chrome vulnerabilities in chains. For general enterprise environments, this should be patched within standard patch cycles (30–60 days) rather than emergency timelines, unless paired with evidence of related renderer exploits in the threat landscape.

Risk score, explained

The CVSS 3.1 score of 6.5 (Medium) reflects: (1) no authentication required and user interaction needed only at the second stage (UI:R), (2) network-adjacent attack surface (AV:N covers the malicious page delivery), (3) high confidentiality impact (C:H) but no integrity or availability loss, and (4) the requirement that an attacker already control the renderer process (a prerequisite not reflected in CVSS). The score underweights the actual barrier to exploitation—renderer compromise—because CVSS does not model prerequisite conditions. In risk prioritization, apply a discount for real-world exploitability given the two-stage requirement.

Frequently asked questions