Insufficient policy enforcement in Navigation in Google Chrome on Android prior to 149

The flaw is a navigation-policy enforcement bypass in Chrome on Android. Based on the user-supplied description, it affects Chrome on Android before the June 2026 Chrome 149 fix train; on Android that shipped as 149.0.7827.59, which Google says carries the same security fixes as the corresponding desktop 149.0.7827.53/54 release. The practical impact is not native code execution; it is bypassing browser navigation restrictions through crafted web content.

Reality is softer than the scary phrasing. The strongest authoritative match I could verify on June 5, 2026 is NVD's CVE-2026-11287, which describes the same bug class in Navigation on Chrome for Android but adds the crucial precondition that the attacker already has a *compromised renderer process*; that turns this from an initial-access bug into an exploit-chain helper. For an enterprise patch queue, that is backlog-grade unless new exploitation evidence appears.

Why this verdict

• Hard downgrade for attacker position: the best primary-source match says the attacker needs a *compromised renderer process* first. That implies post-initial-exploit activity inside Chrome, not a front-door bug.
• Population is narrower than desktop Chrome issues: this is Android-only, client-side, and depends on users browsing attacker content. That is a much smaller and less controllable exposure set than an internet-facing service flaw.
• Threat evidence is cold: no KEV listing, no credible campaign reporting, no public PoC, and EPSS 0.00016 all point to low near-term exploitation pressure.

Why not higher?

A higher rating would require either a stand-alone path to meaningful compromise or proof that this bug is already being chained in the wild. I found neither. The renderer-compromise prerequisite is the killer friction point; it turns the flaw into a helper primitive, not an entry primitive.

Why not lower?

I did not score this IGNORE because it still touches a browser-enforced security boundary on a widely deployed app. In targeted exploit chains, navigation-policy bypasses can improve phishing realism, origin confusion, or chain reliability, so the issue deserves patching—just not a fire drill.

1. Force Play auto-updates for Chrome — Use Android Enterprise / MDM policy to require automatic app updates for com.android.chrome. For a LOW verdict there is no SLA (treat as backlog hygiene), so fold this into routine mobile policy enforcement rather than emergency change control.
2. Alert on stale Chrome builds — Create a compliance rule for Android devices reporting Chrome below 149.0.7827.59. This gives you immediate inventory truth and lets you clean up stragglers during normal maintenance, which is the right cadence for a low-urgency client-side flaw.
3. Reduce alternate browser paths — Limit unmanaged browsers and sideloading on corporate Android devices so users stay on the centrally updated Chrome channel. That shrinks version drift and lowers the chance that stale builds linger in the fleet without visibility.
4. Harden mobile web delivery controls — Keep Safe Browsing, DNS filtering, and mobile threat defense enabled to reduce visits to attacker-controlled pages. These controls do not 'fix' the bug, but they add friction to Step 1 while you remediate in normal backlog order.

Run this from an auditor/admin workstation that has adb installed and can reach a managed Android device over USB or approved remote debugging. Invoke it as ANDROID_SERIAL=<device-serial> ./check_chrome_android.sh; it needs no root on the device, but it does need adb shell access and visibility into the com.android.chrome package metadata.

#!/usr/bin/env bash
# check_chrome_android.sh
# Verify whether Chrome on an attached Android device is below the fixed version.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

PKG="com.android.chrome"
FIXED="149.0.7827.59"
ADB_BIN="${ADB_BIN:-adb}"

ver_lt() {
  local a="$1" b="$2"
  if [[ "$a" == "$b" ]]; then
    return 1
  fi
  [[ "$(printf '%s\n%s\n' "$a" "$b" | sort -V | head -n1)" == "$a" ]]
}

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

if ! "$ADB_BIN" get-state >/dev/null 2>&1; then
  echo "UNKNOWN: no adb device available (set ANDROID_SERIAL if needed)"
  exit 2
fi

version="$($ADB_BIN shell dumpsys package "$PKG" 2>/dev/null | tr -d '\r' | awk -F= '/versionName=/{print $2; exit}')"

if [[ -z "${version:-}" ]]; then
  version="$($ADB_BIN shell cmd package list packages -f "$PKG" 2>/dev/null | tr -d '\r' | sed -n 's/.*com.android.chrome=//p' | head -n1 || true)"
fi

if [[ -z "${version:-}" ]]; then
  echo "UNKNOWN: could not read Chrome version for $PKG"
  exit 2
fi

if ver_lt "$version" "$FIXED"; then
  echo "VULNERABLE: $PKG version $version is below fixed $FIXED"
  exit 1
else
  echo "PATCHED: $PKG version $version is at or above fixed $FIXED"
  exit 0
fi

Sources

1. Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
2. Google Chrome Releases - Chrome for Android Update (June 2, 2026)
3. NVD - CVE-2026-11287
4. Chromium issue tracker reference 502173136
5. Chromium severity guidelines
6. Chrome 149 release notes
7. CISA Known Exploited Vulnerabilities Catalog
8. FIRST EPSS API documentation