CVE-2026-11108 · Chrome Android NFC Improper Privilege Management Sandbox Escape

01 · The Real Story

Like a lockpick that only works if the homeowner hands you the key and holds the door open while you pick it

CVE-2026-11108 is an inappropriate implementation in Google Chrome's Web NFC handler on Android that allows a crafted HTML page to escalate privileges — described as a potential sandbox escape — on Chrome versions prior to 149.0.7827.53. The flaw maps to CWE-269 (Improper Privilege Management) and CWE-648 (Incorrect Use of Privileged APIs). Exploitation requires the victim to (1) visit a malicious page on Chrome for Android, (2) grant the nfc permission via a user gesture, and (3) physically tap their device against an NFC tag while the page is visible, the display is on, and the device is unlocked. The Web NFC API is restricted to HTTPS top-level frames only.

The NVD-assigned CVSS of 8.8 HIGH dramatically overstates real-world risk. Google's own Chromium security team rated this Medium — and they're right. The CVSS vector AV:N/AC:L/PR:N/UI:R treats this as a standard one-click web vuln, but it ignores that 'user interaction' here means *granting a specific device permission AND physically tapping an NFC tag*. That's not a drive-by. The blast radius is a single Android handset, not fleet infrastructure. No exploitation in the wild, no public PoC, EPSS in the 13th percentile (0.225%). This is a Medium-severity logic bug that got a scary CVSS because the scoring framework can't model NFC proximity requirements.

"NFC sandbox escape in Chrome Android is gated by physical tap — real-world risk is Medium, not High."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Victim visits crafted page on Chrome Android

The attacker hosts a malicious HTML page on an HTTPS domain (Web NFC requires secure context) and lures the victim to visit it on Chrome for Android. The page must be in a top-level frame — iframes cannot access Web NFC. This is the social engineering phase — phishing, malvertising, or a watering-hole attack.

Conditions required:

Victim uses Chrome on Android (not desktop, not iOS)
Device has NFC hardware and NFC is enabled in system settings
Victim navigates to attacker-controlled HTTPS page

Where this breaks in practice:

Many enterprise Android devices disable NFC via MDM policy
Chrome on Android auto-updates — the window for unpatched devices shrinks rapidly
Desktop Chrome, iOS Chrome, and all non-Chrome Android browsers are unaffected

Detection/coverage: Standard URL reputation / Safe Browsing will flag known malicious domains. Enterprise web proxies and Secure Web Gateways log the navigation.

STEP 02

Page requests NFC permission via user gesture

The crafted page must trigger an NFC permission prompt through a user gesture (e.g., button click). The user must explicitly tap 'Allow' on the Chrome permission dialog. Without this grant, the Web NFC API is completely inaccessible. The permission is per-origin and can be revoked from site settings.

Conditions required:

User must click a UI element that triggers the permission request
User must approve the NFC permission dialog

Where this breaks in practice:

Users rarely grant NFC permissions to unfamiliar sites
Enterprise Chrome policies can block the nfc permission entirely via PermissionSettings policy
Security-aware users will be suspicious of a random site requesting NFC access

Detection/coverage: Chrome audit logs (if MDM-enrolled) can surface permission grants. No standard scanner detects this step.

STEP 03

User physically taps NFC tag while page is visible

The Web NFC API only activates when the page is visible, the display is on, and the device is unlocked. The user must physically bring their Android device within NFC range (~4 cm) of an NFC tag while the malicious page is in the foreground. This is the critical friction point — the attacker cannot trigger NFC reads remotely.

Conditions required:

Device display must be on and unlocked
Malicious page must be the visible foreground page
User must physically tap or hold device near an NFC tag

Where this breaks in practice:

Requires physical proximity to an NFC tag — attacker must either plant a tag or rely on the user scanning one opportunistically
The attacker has no remote control over when or if this step happens
This transforms a 'remote' attack into one requiring physical-world coordination

STEP 04

NFC handler triggers privilege escalation

The inappropriate implementation in Chrome's NFC processing code mishandles the NFC data or API call in a way that allows the renderer process to escalate privileges. Based on the CWE classification (CWE-269 + CWE-648), this likely involves the NFC code path incorrectly invoking a privileged API or failing to validate privilege boundaries, enabling sandbox escape on the Android device.

Conditions required:

All prior steps must succeed in sequence
Chrome version must be < 149.0.7827.53

Where this breaks in practice:

Scope is S:U (Unchanged) per CVSS — the escalation stays within the same security authority, limiting lateral movement
Android's own sandboxing (SELinux, seccomp-bpf) provides additional containment beyond Chrome's sandbox
No known weaponized exploit or PoC exists to actually reach this step

Detection/coverage: Android's SafetyNet / Play Integrity attestation may detect post-exploitation tampering. EDR agents on managed Android devices (e.g., Microsoft Defender for Endpoint, CrowdStrike Falcon Mobile) can detect anomalous process behavior post-escape.

03 · Compensating Control

MEDIUM 5.0→IGNORE 0.0

SEVERITY REDUCED

Block or disable NFC permission in Chrome via enterprise policy — Deploy ManagedSettings or PermissionSettings MDM policy to block the nfc permission for all origins in Chrome on managed Android devices. This breaks step 2 of the attack chain entirely — the permission dialog never appears. No noisgate mitigation SLA applies for MEDIUM verdicts; go straight to the 365-day remediation window for patching.

MEDIUM 5.0→IGNORE 0.0

SEVERITY REDUCED

Ensure Chrome auto-update is enabled on all managed Android devices — Verify via your MDM (Intune, Workspace ONE, JAMF, etc.) that Google Play auto-updates are enabled and Chrome is on version ≥149.0.7827.53. The fix shipped nearly 4 months ago — any device still unpatched likely has a configuration problem. Remediate within the 365-day noisgate remediation SLA.

MEDIUM 5.0→IGNORE 0.0

SEVERITY REDUCED

Disable NFC at the OS level on devices that don't require it — For managed devices where NFC is not business-critical, disable NFC in Android system settings via MDM device restriction profile. This eliminates the entire attack surface regardless of Chrome version.

MEDIUM 5.0→LOW 3.0

SEVERITY REDUCED

Deploy mobile threat defense (MTD) agent on managed devices — MTD solutions (Microsoft Defender for Endpoint, CrowdStrike Falcon Mobile, Lookout, Zimperium) can detect post-exploitation anomalies like sandbox escape artifacts and unauthorized privilege escalation on Android. This doesn't prevent exploitation but provides detection and response capability.

What doesn't work

Network-level WAF/IDS — This is a client-side browser vulnerability triggered by visiting a page. There is no server-side payload signature to detect. Web Application Firewalls inspect inbound traffic to your servers, not outbound browsing from your endpoints.
Disabling NFC tags in the environment — You don't control what NFC tags exist in the physical world. An attacker could plant a tag anywhere. However, the Chrome permission gate still applies regardless of tag placement.
Chrome site isolation / process-per-site — Site isolation protects against cross-site data leaks between renderer processes. It does not prevent a privilege escalation from the NFC handler within the same renderer's security context.

04 · Intelligence Metadata

The supporting signals.

In-the-Wild Exploitation	None observed. Not listed in CISA KEV. No campaigns, APT usage, or incident reports reference this CVE as of 2026-09-30.
Proof-of-Concept Availability	No public PoC found. Checked pocindex.io (no entry), GitHub (no repos named CVE-2026-11108), ExploitDB, and nomi-sec/PoC-in-GitHub. The Chromium bug (#500517053) is access-restricted.
EPSS Score	0.00225 (0.225%) — 13th percentile. Indicates extremely low predicted exploitation probability in the next 30 days.
KEV Status	Not listed in the CISA Known Exploited Vulnerabilities catalog.
CVSS Vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H` — 8.8 HIGH per NVD. Chromium rates this Medium. The vector's `UI:R` undersells the actual interaction burden (permission grant + physical NFC tap).
Affected Versions	Google Chrome on Android only, all versions prior to 149.0.7827.53. Desktop Chrome (Windows, macOS, Linux) and Chrome on iOS are not affected.
Fixed Version	Chrome 149.0.7827.53 (Stable channel, released early June 2026). Android Chrome auto-updates via Play Store; most devices patched within 1-2 weeks of release.
Scanning / Exposure	Not applicable for GreyNoise/Shodan/Censys — this is a client-side mobile browser vulnerability, not a server-side exposure. No internet-facing attack surface to enumerate.
Disclosure Date	2026-06-04 — nearly 4 months ago. Auto-update has had ample time to propagate the fix.
Reporting Researcher	Not publicly disclosed. The Chromium issue tracker entry (#500517053) is access-restricted; reporter identity is not available in public references.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (5.0/10)

Why this verdict

Chromium disagrees with NVD: Google's own security team rated this Medium, not High. The vendor who wrote and patched the code assessed a lower severity than NVD's automated CVSS assignment — Chromium's rating accounts for the NFC-specific interaction requirements that CVSS cannot model.
Multi-gate physical interaction chain: The CVSS UI:R flag treats this like a one-click phishing link. In reality, exploitation requires (1) visiting the page, (2) granting NFC permission through a dialog, AND (3) physically tapping an NFC tag while the page is visible. Each gate independently filters out the vast majority of potential victims. This is not AC:L in any operational sense.
Android-only, client-side, single-device blast radius: This affects Chrome on Android handsets — not servers, not desktops, not infrastructure. A successful exploit compromises one phone. There is no pivot to domain takeover, fleet compromise, or supply-chain impact from an NFC handler bug on a mobile browser.
Role multiplier: Chrome on Android occupies no high-value infrastructure role. It is an end-user mobile browser. It does not run on domain controllers, hypervisors, CI/CD runners, backup appliances, PKI/CA, PAM, or network edge devices. The worst plausible deployment role is a corporate BYOD phone with email/Slack access — the blast radius is one user's mobile session, not fleet-scale or identity-scale. The high-value-role floor does NOT apply.
No exploitation evidence, no PoC, minimal EPSS: Zero in-the-wild exploitation, no public PoC, not in KEV, EPSS at 0.225% (13th percentile). After nearly 4 months since disclosure, no attacker has found this worth weaponizing — consistent with the extreme operational friction.
Auto-update neutralizes exposure window: Chrome on Android updates automatically via the Play Store. The fix shipped in early June 2026. By now (late September 2026), the residual unpatched population is minimal — primarily devices with disabled auto-updates or abandoned/unmanaged phones.

Why not higher?

The absence of any exploitation in the wild, public PoC, or KEV listing — combined with Chromium's own Medium rating and the extraordinary physical interaction requirements (NFC permission grant + physical tag tap) — make HIGH or CRITICAL unjustifiable. The CVSS 8.8 score is an artifact of a scoring framework that cannot distinguish 'click a link' from 'grant a rare permission and physically tap an NFC tag.' The blast radius is a single mobile device with no infrastructure pivot potential.

Why not lower?

Despite the friction, this *is* a sandbox escape on a browser used by billions. The impact if successfully exploited (C:H/I:H/A:H) is real — an attacker gains elevated privileges on the device. Chrome's massive installed base means even a small percentage of vulnerable devices is a large absolute number. The NFC attack surface, while niche, is not purely theoretical — NFC is standard on modern Android phones. LOW would understate the *potential* impact for the subset of devices that remain unpatched with NFC enabled.

06 · Verification

Crowdsourced verification payload.

Run this on each managed Android device via adb shell or push it through your MDM's script execution framework. Requires adb access or shell execution capability on the target device. Example: adb shell sh /data/local/tmp/check_cve_2026_11108.sh

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/system/bin/sh
# CVE-2026-11108 Checker — Chrome NFC Privilege Escalation (Android only)
# Checks if installed Chrome version is >= 149.0.7827.53 (patched)
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

TARGET_MAJOR=149
TARGET_MINOR=0
TARGET_BUILD=7827
TARGET_PATCH=53

# Get Chrome version from package manager
CHROME_VERSION=$(dumpsys package com.android.chrome 2>/dev/null | grep versionName | head -1 | sed 's/.*versionName=//' | tr -d '[:space:]')

if [ -z "$CHROME_VERSION" ]; then
  echo "UNKNOWN — Chrome not installed or not accessible via dumpsys"
  exit 2
fi

# Parse version components
MAJOR=$(echo "$CHROME_VERSION" | cut -d. -f1)
MINOR=$(echo "$CHROME_VERSION" | cut -d. -f2)
BUILD=$(echo "$CHROME_VERSION" | cut -d. -f3)
PATCH=$(echo "$CHROME_VERSION" | cut -d. -f4)

if [ -z "$MAJOR" ] || [ -z "$BUILD" ]; then
  echo "UNKNOWN — Could not parse Chrome version: $CHROME_VERSION"
  exit 2
fi

# Check if NFC hardware is present
NFC_PRESENT=$(pm list features 2>/dev/null | grep -c 'android.hardware.nfc')

# Version comparison
if [ "$MAJOR" -gt "$TARGET_MAJOR" ]; then
  echo "PATCHED — Chrome $CHROME_VERSION >= 149.0.7827.53"
  exit 0
elif [ "$MAJOR" -eq "$TARGET_MAJOR" ]; then
  if [ "$BUILD" -gt "$TARGET_BUILD" ]; then
    echo "PATCHED — Chrome $CHROME_VERSION >= 149.0.7827.53"
    exit 0
  elif [ "$BUILD" -eq "$TARGET_BUILD" ] && [ "${PATCH:-0}" -ge "$TARGET_PATCH" ]; then
    echo "PATCHED — Chrome $CHROME_VERSION >= 149.0.7827.53"
    exit 0
  fi
fi

if [ "$NFC_PRESENT" -eq 0 ]; then
  echo "PATCHED — Chrome $CHROME_VERSION is outdated but device lacks NFC hardware (not exploitable)"
  exit 0
fi

echo "VULNERABLE — Chrome $CHROME_VERSION < 149.0.7827.53 on NFC-capable device"
exit 1