Insufficient validation of untrusted input in Reader Mode in Google Chrome on Android prior to 149

CVE-2026-11297 is an improper input validation bug in Reader Mode in Google Chrome on Android. Affected versions are Chrome on Android before 149.0.7827.53; Google’s June 2, 2026 Chrome 149 stable release notes list this issue as Low severity, and the CVE description says exploitation requires a local attacker and a malicious file to bypass Reader Mode navigation restrictions.

The published 7.7/HIGH CVSS from CISA-ADP overstates real enterprise risk. In practice this is a local, post-initial-access, single-device issue with no evidence of internet-scale exposure, no KEV listing, near-zero EPSS, and impact that appears limited to a browser policy/navigation boundary rather than remote code execution or cross-device compromise.

Why this verdict

• Local-only prerequisite: AV:L means the attacker needs on-device presence, physical access, or an already-malicious app. That is post-initial-access, and each prerequisite compounds downward pressure on severity.
• Niche reachable population: the vulnerable path is Reader Mode with a malicious file, not mainstream remote web content at internet scale. Only a subset of Android Chrome users will ever exercise this path in ways an attacker can control.
• Weak threat intel: no KEV listing, no active exploitation evidence, and an EPSS of 0.00007 all argue against emergency treatment.
• Limited blast radius: even successful exploitation appears confined to one Android device and one browser context; there is no evidence of tenant-wide, domain-wide, or server-side compromise.
• Vendor reality check: Google itself tagged the issue Low in Chrome 149 release notes, which better reflects field conditions than the abstract CISA-ADP CVSS baseline.

Why not higher?

This is not unauthenticated remote code execution, not a wormable service bug, and not an externally reachable enterprise server flaw. The attacker must already be on the device or able to stage a malicious local file, which is exactly the kind of prerequisite that should crush priority for fleet patching.

Why not lower?

It still crosses a security boundary inside Chrome and is fixed in a stable release, so it is not noise. If you run managed Android fleets, kiosks, or shared frontline devices where Chrome is a business-critical access path, there is still value in rolling the update during normal hygiene.

1. Block unmanaged app installs — Use MDM/UEM policy to prevent sideloading and restrict unknown app sources, because the most realistic precursor is a malicious local app staging the crafted file. For a LOW verdict there is no mitigation SLA (treat as backlog hygiene), so apply this through normal mobile hardening cadence.
2. Restrict Chrome version drift — Enforce minimum Chrome versions on managed Android devices and flag anything below 149.0.7827.53. For a LOW verdict there is no remediation SLA (treat as backlog hygiene), so handle this in your next standard mobile app update cycle.
3. Constrain local file handling — Where business permits, limit unmanaged file shares, personal storage, and open-with flows into Chrome from untrusted apps or profiles. This reduces the chance that a crafted local file reaches the vulnerable Reader Mode path, and it can be rolled out during normal policy maintenance for this LOW issue.
4. Use work profile separation — Keep enterprise accounts and data inside managed work profiles so a compromised personal-side app has less leverage over enterprise Chrome usage. This is a durable compensating control and fits normal backlog-hygiene timing for a LOW finding.

Run this on an auditor workstation or admin laptop with Android Platform Tools (adb) installed and a USB- or network-connected managed Android device. Invoke it as ./check_cve_2026_11297.sh com.android.chrome; it needs ADB access to the target device, but not root.

#!/usr/bin/env bash
# check_cve_2026_11297.sh
# Determine whether Google Chrome on Android is vulnerable to CVE-2026-11297.
# Usage: ./check_cve_2026_11297.sh [package_name]
# Example: ./check_cve_2026_11297.sh com.android.chrome
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / error

set -u

PKG="${1:-com.android.chrome}"
FIXED="149.0.7827.53"

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

if ! adb get-state >/dev/null 2>&1; then
  echo "UNKNOWN: no ADB device available"
  exit 2
fi

VERSION_LINE=$(adb shell dumpsys package "$PKG" 2>/dev/null | tr -d '\r' | grep -m1 'versionName=')
if [ -z "$VERSION_LINE" ]; then
  echo "UNKNOWN: package '$PKG' not found or versionName unavailable"
  exit 2
fi

INSTALLED="${VERSION_LINE#*=}"
INSTALLED="${INSTALLED%% *}"

# Compare dotted versions using sort -V.
LOWEST=$(printf '%s\n%s\n' "$INSTALLED" "$FIXED" | sort -V | head -n1)

if [ "$INSTALLED" = "$FIXED" ]; then
  echo "PATCHED: $PKG version $INSTALLED meets fixed version $FIXED"
  exit 0
fi

if [ "$LOWEST" = "$INSTALLED" ]; then
  echo "VULNERABLE: $PKG version $INSTALLED is older than fixed version $FIXED"
  exit 1
else
  echo "PATCHED: $PKG version $INSTALLED is newer than fixed version $FIXED"
  exit 0
fi

Sources

1. NVD CVE-2026-11297
2. Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
3. Chrome Releases - Chrome for Android Update (May 28, 2026)
4. Chrome Releases - Chrome for Android Update (May 5, 2026)
5. Chrome Releases - Early Stable Update for Desktop (May 29, 2026)
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS Data and Statistics
8. MITRE CWE-20 Improper Input Validation