CVE-2026-13939: Chrome Android WebShare UI Spoofing – Update to 150.0.7871.47

Technical summary

CVE-2026-13939 is a UI spoofing vulnerability in the WebShare implementation of Google Chrome on Android prior to version 150.0.7871.47. The root cause is insufficient validation of untrusted input passed to WebShare functionality. An attacker who has compromised the renderer process can craft a malicious HTML page that bypasses input validation checks, resulting in the rendering of deceptive UI elements. The vulnerability is classified as CWE-20 (Improper Input Validation) and carries a CVSS 3.1 score of 3.1 (LOW severity) with vector CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N, reflecting the requirement for high attack complexity and user interaction, with integrity impact limited to the user's perception rather than data compromise.

Business impact

This vulnerability presents minimal direct business risk to most organizations. The attack requires an attacker to have already compromised the renderer process—a significant prerequisite that typically requires an earlier vulnerability or substantial system compromise. The integrity impact is confined to visual spoofing rather than unauthorized access, data exfiltration, or system manipulation. Organizations should monitor for active exploitation in the wild, but the low CVSS score and high attack complexity mean this is unlikely to be a primary vector in targeted attacks. The main concern would be in scenarios where this is chained with other vulnerabilities to amplify a multi-stage compromise.

Affected systems

Google Chrome on Android devices running versions prior to 150.0.7871.47 are affected. The vulnerability is specific to the Android platform; Chrome on other operating systems (Windows, macOS, Linux, iOS) is not impacted by this particular flaw. Organizations managing Android devices with Chrome as the primary browser should prioritize inventory and patch tracking, though the limited attack surface means this is not an emergency.

Exploitability

Exploitability is constrained by multiple factors. An attacker must first compromise the renderer process itself, which is a non-trivial prerequisite requiring either a separate renderer vulnerability or successful code injection. Additionally, the attack vector requires user interaction (UI:R in the CVSS vector), meaning the victim must engage with the spoofed interface in a way the attacker finds valuable. The high attack complexity (AC:H) further limits real-world exploitation. This is not a self-contained remote code execution vulnerability and cannot be exploited by simply sending a malicious link. The vulnerability has not been added to CISA's KEV catalog, indicating no evidence of active exploitation in the wild as of the publication date.

Remediation

Users should update Google Chrome on Android to version 150.0.7871.47 or later. Verify the installed version in Chrome's settings (Menu > Settings > About Chrome) to confirm the update has been applied. Android devices will typically receive updates through the Google Play Store. If automatic updates are enabled, this should happen within days of the release; manual checks can be forced through the Play Store app. Enterprise administrators managing Android devices should deploy updates through mobile device management (MDM) solutions and verify compliance within their inventory systems.

Patch guidance

The fix is available in Chrome version 150.0.7871.47 and later. Deployment priority should be standard—not emergency—given the low CVSS score and exploitation constraints. For organizations with large Android deployments, staged rollout is reasonable to catch any unforeseen compatibility issues, though none have been reported. Verify patch application by checking the Chrome version string in about:chrome or the device settings. If your organization uses Chrome enterprise policies, ensure no legacy version pinning policies are preventing automatic updates.

Detection guidance

Detection of exploitation would require identifying renderer process compromises through browser process monitoring, as the vulnerability itself manifests as visual spoofing rather than network-observable behavior. Security operations teams should look for: (1) unexpected Chrome renderer crashes or restart events, which may indicate exploitation attempts; (2) indicators of prior compromise (malware, unauthorized code execution, suspicious browser extensions); and (3) user reports of unusual sharing dialogs or UI elements from WebShare functionality. Standard endpoint detection and response (EDR) tools can flag suspicious renderer process activity if configured with appropriate behavioral rules. Network-level detection is not practical for this vulnerability.

Why prioritize this

Prioritize this vulnerability with standard urgency rather than critical. While it affects a widely deployed browser, the low CVSS score (3.1), requirement for renderer process compromise, user interaction requirement, and lack of evidence in CISA's KEV catalog all point to limited real-world impact. Remediation should be handled through routine patch cycles rather than emergency procedures. Organizations should verify their Android update deployment mechanisms are functioning correctly and ensure Chrome is included in their mobile app patch inventory, but this is not a patch-now-or-face-breach scenario.

Risk score, explained

The CVSS 3.1 score of 3.1 reflects the convergence of several mitigating factors: Network-accessible attack vector (AV:N) is balanced by high attack complexity (AC:H, requiring prior renderer compromise). The requirement for user interaction (UI:R) further reduces severity. Most importantly, the impact is limited to integrity (I:L) with no confidentiality or availability impact. The integrity impact itself is non-standard—it affects UI presentation rather than data integrity, meaning an attacker can deceive users visually but cannot steal information or crash the browser. This results in a LOW severity rating despite being remotely triggered.

Frequently asked questions