CVE-2026-11108: Chrome Android NFC Sandbox Escape Vulnerability – Patch Guidance
A flaw in how Google Chrome handles NFC (Near Field Communication) on Android devices allows an attacker to trick a user into visiting a malicious website, which can then escape the browser sandbox and gain elevated privileges on the device. The vulnerability requires user interaction—specifically clicking a link or visiting a page—but does not require the attacker to be network-adjacent or have special system access. Once exploited, an attacker gains the same privileges as the Chrome browser process, potentially enabling access to sensitive data or further system compromise.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 8.8 HIGH · CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
- Weaknesses (CWE)
- CWE-269
- Affected products
- 2 configuration(s)
- Published / Modified
- 2026-06-04 / 2026-06-17
NVD description (verbatim)
Inappropriate implementation in NFC in Google Chrome on Android prior to 149.0.7827.53 allowed a remote attacker to perform privilege escalation via a crafted HTML page. (Chromium security severity: Medium)
2 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
CVE-2026-11108 is a privilege escalation vulnerability in the NFC implementation within Google Chrome on Android. The root cause is classified as CWE-269 (Improper Assertion), indicating that the browser fails to properly validate or assert security constraints in the NFC code path. An attacker can craft a malicious HTML page that, when visited by a user, leverages the NFC handling flaw to escape Chrome's sandbox and execute code with elevated privileges. The vulnerability affects Chrome versions prior to 149.0.7827.53 on Android. While Chromium's internal severity rating is Medium, the CVSS v3.1 score of 8.8 reflects the high impact: network-accessible, low complexity attack surface with user interaction, and resulting compromise of confidentiality, integrity, and availability.
Business impact
For organizations supporting Android devices in their workforce, this vulnerability poses a direct risk to enterprise security. A compromised device can become a foothold for lateral network movement, data exfiltration, or credential theft. The attack vector—a crafted HTML page—is difficult to prevent through network controls alone, as users may be socially engineered or encounter the malicious page through legitimate browsing. Industries handling sensitive data, financial services, healthcare, and government entities face elevated risk. Device management and compliance frameworks may be circumvented if Chrome sandbox escapes allow installation of monitoring tools or access to encrypted credentials.
Affected systems
Google Chrome on Android versions prior to 149.0.7827.53 are vulnerable. The vulnerability is specific to Android; Chrome on Windows, macOS, and Linux are not affected by this particular NFC flaw. Both end-user devices and organization-managed Android devices running Chrome are at risk. The scope includes any Android user agent running an outdated Chrome build—in practice, this spans devices running Android 8.0 and later that have Chrome installed and have not yet auto-updated to the patched version.
Exploitability
Exploitation requires a user to visit a crafted HTML page delivered over the network. No authentication, special network positioning, or local access is required from the attacker's perspective. The attack complexity is low, and the user interaction needed is a normal browsing action. Given the prevalence of phishing, drive-by downloads, and malvertising, the practical exploitability is high. There are no known public exploits or KEV listing as of the data snapshot, but the straightforward attack surface suggests proof-of-concept development is likely. In real-world scenarios, attackers would combine this with social engineering to increase click-through rates.
Remediation
The primary remediation is to update Google Chrome on Android to version 149.0.7827.53 or later. Chrome's auto-update mechanism on Android typically pushes updates within days, but users should verify their current version in Chrome's settings (Menu > About Chrome) and manually trigger an update if needed. For organizations managing Android devices via MDM (Mobile Device Management) solutions, push the latest Chrome update through your policy framework and verify deployment. Until patching is possible, restrict user browsing to internal or well-vetted websites and educate users to avoid clicking suspicious links.
Patch guidance
Google has released version 149.0.7827.53 of Chrome for Android with the fix. Verify compatibility with your supported Android OS versions before rollout. For enterprise deployments: (1) Test the patched Chrome version in a lab environment on representative Android devices and OS levels. (2) Stage the update via MDM or configure auto-update policies. (3) Monitor deployment completion and correlate with your asset inventory. (4) Document the patched version in your change management system. Users on personal devices should enable auto-update in the Play Store and check Settings > Apps > Google Chrome > App details for the current version. Patch urgently given the HIGH CVSS score and the ease of attack delivery.
Detection guidance
Monitor for Chrome process crashes or unexpected privilege elevation on Android devices. Logs from MDM platforms can track Chrome app version adoption over time. Network detection is challenging since the attack uses standard HTTPS traffic to deliver the malicious page; focus instead on behavioral indicators: unusual app installations following a Chrome update, unexpected network exfiltration, or device management policy violations post-compromise. Endpoint detection tools with Android support should flag any attempt to run code outside Chrome's designated sandbox. For those with access to Chrome crash logs (via Chromium crash reporting), watch for crashes in the NFC handling code paths. User awareness training should highlight the risk of clicking links from untrusted sources, particularly those promising unusual functionality or requiring device permissions.
Why prioritize this
This vulnerability merits immediate attention due to the combination of high CVSS score (8.8), straightforward attack vector (user browsing), lack of KEV status indicating no active weaponization yet (but likely imminent), and the widespread use of Chrome on Android. The privilege escalation outcome creates a severe confidentiality, integrity, and availability impact. Delayed patching leaves devices vulnerable to targeted or mass exploitation campaigns. While Chromium's severity is rated Medium, the objective CVSS score and real-world exploitation ease justify prioritizing this above routine patches.
Risk score, explained
The CVSS v3.1 score of 8.8 (HIGH) reflects: (1) Network Attack Vector (AV:N)—no special access or proximity required. (2) Low Attack Complexity (AC:L)—no special conditions or evasion techniques needed. (3) No Privileges Required (PR:N)—attacker does not need prior system access. (4) Required User Interaction (UI:R)—user must visit a malicious page, a realistic scenario. (5) Unchanged Scope (S:U)—impact is limited to the vulnerable component, but given sandbox escape, this is effectively a scope change. (6) High Confidentiality, Integrity, and Availability impact (C:H/I:H/A:H)—code execution with elevated privileges can access or modify any data the Chrome process can, and crash the browser or device. This score appropriately captures a sandbox escape as a severe risk, even though Chromium's internal assessment is Medium.
Frequently asked questions
Why does the Chromium severity say Medium but the CVSS score is 8.8 (HIGH)?
Chromium's internal severity rating considers factors specific to the browser ecosystem and attack surface, while CVSS is a standardized metric focusing on technical exploitability and impact. In this case, CVSS correctly reflects that sandbox escape with privilege escalation is objectively a high-severity outcome. Chromium's Medium rating may emphasize that the attack requires user interaction and depends on NFC-specific code paths. Both assessments are valid in context; CVSS provides a comparable score for prioritization across different vulnerabilities.
If this isn't on the KEV list yet, how urgent is patching?
KEV (Known Exploited Vulnerabilities) status indicates active, real-world exploitation tracked by CISA. This vulnerability is not currently KEV-listed, meaning there is no public evidence of widespread exploitation at the time of disclosure. However, KEV is a trailing indicator—vulns are added after exploitation is observed. Given the high CVSS, ease of delivery (malicious webpage), and the privilege escalation impact, it is prudent to treat this as pre-KEV and patch within days, not weeks. Waiting for KEV status before patching is a known anti-pattern.
Does this affect Chrome on my laptop or desktop?
No. This vulnerability is specific to Chrome on Android and stems from how the browser handles NFC hardware on mobile devices. Chrome on Windows, macOS, and Linux does not use NFC and is unaffected. If you support Android devices in your organization, those are your concern; desktops can be deprioritized for this particular fix.
What if a user has Chrome auto-update disabled?
Chrome on Android typically ships with auto-update enabled by default via the Google Play Store. If a user has manually disabled auto-update, the patch will not install automatically. Enterprise MDM can enforce installation of the patched version regardless of user settings. For personal devices, educate users to re-enable Play Store auto-update or manually visit the Play Store and update Chrome. Given the severity, follow up on devices that remain unpatched after a reasonable grace period (e.g., 7–10 days).
This analysis is provided for informational purposes and reflects the vulnerability status as of the publication and modification dates shown. CVSS scores, affected versions, and patch information are based on official vendor disclosures and should be verified against the latest Google Chrome and Android security advisories. Organizations should conduct their own risk assessments based on their specific environment, asset inventory, and business context. No liability is assumed for errors or omissions. Always consult vendor security bulletins and MDM platform documentation before deploying patches in production environments. Source: NVD (public-domain), retrieved 2026-07-12. Analysis generated by SEC.co (claude-haiku-4-5).
Related vulnerabilities
- CVE-2026-0009HIGHAndroid Tapjacking Local Privilege Escalation Vulnerability
- CVE-2026-0089HIGHAndroid PackageInstallerService Permission Check Bypass – Local Privilege Escalation
- CVE-2026-0091HIGHAndroid Launcher Privilege Escalation Vulnerability (CVSS 7.8)
- CVE-2026-11103HIGHChrome Installer Privilege Escalation on Windows
- CVE-2026-9892HIGHChrome Android Sandbox Escape in Skia Graphics Library
- CVE-2026-9999HIGHANGLE Sandbox Escape in Google Chrome macOS – Exploitation & Patch Guidance
- CVE-2026-0016LOWAndroid Credential Manager Permission Bypass & Cross-User Data Disclosure
- CVE-2026-0046MEDIUMAndroid Tapjacking Permission Escalation Vulnerability