Inappropriate implementation in NFC in Google Chrome on Android prior to 149

CVE-2026-11108 is an *inappropriate implementation* bug in Chrome's NFC handling on Android. A malicious site can drive the vulnerable code path with crafted HTML, but the affected population is limited to Google Chrome on Android before 149.0.7827.53.

The vendor-style 8.8/HIGH score overstates operational risk for enterprise patching because it models the impact once the bug is reached, not the real-world friction required to reach it. Web NFC on Chrome for Android is gated behind top-level HTTPS, user gesture, user permission, visible unlocked page state, NFC-capable hardware, NFC being enabled, and usually an NFC interaction path at close range; that stack of prerequisites is why this behaves more like a medium-priority mobile client bug than a broad internet emergency.

Why this verdict

• Physical-world gating reduced the score: Chrome's Web NFC flow requires top-level HTTPS, visible unlocked page state, user gesture, permission grant, NFC-capable hardware, NFC enabled, and usually tag proximity.
• Client-only exposure reduced the score: this is Android Chrome, not an internet-facing daemon, so attackers cannot mass-scan and slam it the way they would a perimeter RCE.
• No threat signal reduced the score: no KEV listing, no public PoC found, and the supplied EPSS of 0.00035 all argue against near-term broad weaponization.

Why not higher?

If this were a zero-click browser bug, a no-permission API path, or a sandbox escape with demonstrated exploitation, it would stay in HIGH or go higher. The real chain here is narrower: Android-only plus Web NFC plus user-and-device conditions is simply not broad enough to justify emergency treatment.

Why not lower?

It is still a privilege-escalation bug in Chrome, which is one of the most deployed applications on managed Android devices. If your organization uses NFC-enabled Android kiosks, field devices, badge workflows, or payment-adjacent mobile roles, the reachable subset is meaningful enough that this should not be ignored.

1. Disable NFC where it is not a business requirement — Use EMM/MDM policy to turn off NFC on managed Android devices that do not need it. For a MEDIUM verdict there is no noisgate mitigation SLA; this is optional risk reduction, but it is the single best compensating control while you work through the 365-day remediation window.
2. Reset or deny Chrome NFC site permissions — Where your mobile management stack supports it, clear prior site permissions or enforce restrictive browser permission defaults so hostile pages cannot reuse earlier NFC grants. There is no mitigation SLA for MEDIUM; apply as defense-in-depth on higher-risk Android cohorts such as kiosks, shared devices, and field phones.
3. Prioritize managed Android cohorts with NFC workflows — Segment devices used for badge scanning, asset tagging, retail, logistics, or kiosk workflows because those are the fleets most likely to satisfy the NFC prerequisite chain. For MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window, but these cohorts deserve first patch priority inside that window.
4. Use mobile URL filtering and Safe Browsing enforcement — This will not fix the bug, but it reduces the chance that users ever reach attacker-controlled pages that try to invoke Web NFC. Apply on managed Android browsers as standard hygiene while patching through the normal remediation cycle.

Run this from an auditor workstation that has adb installed and authorized access to the target Android device. Invoke it as ./check_cve_2026_11108.sh <device-serial>; example: ./check_cve_2026_11108.sh R58N123ABCD. It needs access to adb shell dumpsys package com.android.chrome; root is not required, but USB debugging or enterprise ADB access is.

#!/usr/bin/env bash
# check_cve_2026_11108.sh
# Verifies whether Google Chrome on an attached Android device is older than 149.0.7827.53.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

TARGET_FIXED="149.0.7827.53"
PKG="com.android.chrome"

usage() {
  echo "Usage: $0 <device-serial>" >&2
  exit 2
}

ver_to_ints() {
  local IFS='.'
  local parts=($1)
  printf "%d %d %d %d\n" \
    "${parts[0]:-0}" "${parts[1]:-0}" "${parts[2]:-0}" "${parts[3]:-0}"
}

ver_lt() {
  local a b c d w x y z
  read -r a b c d <<< "$(ver_to_ints "$1")"
  read -r w x y z <<< "$(ver_to_ints "$2")"

  [[ $a -lt $w ]] && return 0
  [[ $a -gt $w ]] && return 1
  [[ $b -lt $x ]] && return 0
  [[ $b -gt $x ]] && return 1
  [[ $c -lt $y ]] && return 0
  [[ $c -gt $y ]] && return 1
  [[ $d -lt $z ]] && return 0
  return 1
}

[[ $# -eq 1 ]] || usage
SERIAL="$1"

if ! command -v adb >/dev/null 2>&1; then
  echo "UNKNOWN: adb not found in PATH"
  exit 2
fi

if ! adb -s "$SERIAL" get-state >/dev/null 2>&1; then
  echo "UNKNOWN: device $SERIAL not reachable via adb"
  exit 2
fi

RAW_VERSION=$(adb -s "$SERIAL" shell dumpsys package "$PKG" 2>/dev/null | sed -n 's/.*versionName=\([^[:space:]]*\).*/\1/p' | head -n1 | tr -d '\r')

if [[ -z "$RAW_VERSION" ]]; then
  echo "UNKNOWN: could not read Chrome version or package $PKG is absent"
  exit 2
fi

if [[ ! "$RAW_VERSION" =~ ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
  echo "UNKNOWN: unexpected version format: $RAW_VERSION"
  exit 2
fi

if ver_lt "$RAW_VERSION" "$TARGET_FIXED"; then
  echo "VULNERABLE: Chrome $RAW_VERSION is older than fixed version $TARGET_FIXED"
  exit 1
else
  echo "PATCHED: Chrome $RAW_VERSION is at or newer than fixed version $TARGET_FIXED"
  exit 0
fi

Sources

1. Chrome Releases archive for June 2026
2. Chrome for Android Update (149.0.7827.48 rollout)
3. Web NFC on Chrome for Android documentation
4. CIRCL Vulnerability Lookup entry for CVE-2026-11108
5. CISA Known Exploited Vulnerabilities catalog
6. FIRST EPSS API documentation
7. Google Chrome update instructions for Android