Insufficient validation of untrusted input in Shortcuts in Google Chrome on Mac prior to 149

CVE-2026-11283 is a navigation-restriction bypass in Chrome's Shortcuts handling on macOS before 149.0.7827.53. The public description says a remote attacker can use a malicious file to make vulnerable Chrome on Mac bypass intended navigation limits; this is not described as code execution, sandbox escape, or data theft on its own.

Google's vendor CVSS of 6.5 / MEDIUM overstates the operational urgency for enterprise patching. In the real world this chain is narrowed by platform scope (Mac only), delivery mode (malicious file, not clean drive-by HTML), required user interaction, and impact limited to browser policy/navigation integrity rather than full host compromise.

Why this verdict

• Mac-only scope cuts the population hard: this is not a Windows/Linux fleet event, so large mixed-platform estates should expect materially lower affected-host counts than the raw Chrome install base suggests.
• Delivery requires a malicious file and user action: that implies phishing, download lure, or similar pretext. This is downward pressure because the attacker is not simply landing code from a normal webpage visit.
• Impact is integrity-limited: the public description is navigation restriction bypass, not RCE, sandbox escape, credential theft, or arbitrary file read by itself.
• No exploitation heat: not in KEV, no public PoC located, and the supplied EPSS of 0.0002 is near noise floor.
• Vendor baseline looks vacuum-scored: the 6.5 MEDIUM mostly reflects a generic remote+UI-required integrity issue, but it does not adequately price in platform narrowing and client-side delivery friction.

Why not higher?

This does not present as an internet-facing, unauthenticated, one-click web exploit with broad fleet reach. The absence of code-execution impact, combined with Mac-only targeting and malicious-file delivery, keeps it well below a modern enterprise HIGH threshold.

Why not lower?

It is still a real trust-boundary failure in a heavily deployed browser, and remote attackers can plausibly chain it into phishing or browser-deception workflows. If you run a sizeable managed Mac population, it deserves routine patching and inventory attention rather than being dismissed outright.

1. Force Chrome auto-update on managed Macs — Use your browser-management stack to keep macOS Chrome on 149.0.7827.53+. For a LOW verdict there is no SLA beyond backlog hygiene, so land this in the next normal browser-update wave rather than as an emergency change.
2. Tighten risky file-delivery paths — Reduce successful trigger opportunities by blocking or warning on suspicious downloaded files from email, chat, and unmanaged cloud shares. Again, for LOW, treat this as backlog hygiene and fold it into your standard hardening cycle.
3. Preserve download and quarantine telemetry — Make sure macOS quarantine attributes, EDR file-open telemetry, and browser download logs are retained so you can reconstruct any malicious-file delivery chain. This is useful for investigation even though it is not a priority emergency control for a LOW finding.
4. Prioritize Mac browser inventory accuracy — Because this CVE is macOS-specific, accurate asset scoping is more valuable than broad panic patching. Treat version validation on managed Macs as routine hygiene and close the gap in the next standard reporting cycle.

Run this on the target Mac endpoint as a normal user; admin rights are not required to read the app bundle version. Save as verify_cve_2026_11283.sh and run bash verify_cve_2026_11283.sh "/Applications/Google Chrome.app".

#!/bin/bash
# verify_cve_2026_11283.sh
# Checks whether Google Chrome on macOS is below 149.0.7827.53
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

TARGET_VERSION="149.0.7827.53"
APP_PATH="${1:-/Applications/Google Chrome.app}"
PLIST="$APP_PATH/Contents/Info.plist"

compare_versions() {
  # returns 0 if equal, 1 if $1 > $2, 2 if $1 < $2
  local IFS=.
  local i
  local -a v1=($1) v2=($2)

  for ((i=${#v1[@]}; i<4; i++)); do v1[i]=0; done
  for ((i=${#v2[@]}; i<4; i++)); do v2[i]=0; done

  for i in 0 1 2 3; do
    if ((10#${v1[i]} > 10#${v2[i]})); then
      return 1
    elif ((10#${v1[i]} < 10#${v2[i]})); then
      return 2
    fi
  done
  return 0
}

if [[ "$(uname -s)" != "Darwin" ]]; then
  echo "UNKNOWN: This verification script is intended for macOS (Darwin)."
  exit 2
fi

if [[ ! -d "$APP_PATH" ]]; then
  echo "UNKNOWN: Chrome app not found at $APP_PATH"
  exit 2
fi

if [[ ! -f "$PLIST" ]]; then
  echo "UNKNOWN: Info.plist not found at $PLIST"
  exit 2
fi

INSTALLED_VERSION=$(/usr/bin/defaults read "$PLIST" CFBundleShortVersionString 2>/dev/null)

if [[ -z "$INSTALLED_VERSION" ]]; then
  echo "UNKNOWN: Could not read Chrome version from $PLIST"
  exit 2
fi

compare_versions "$INSTALLED_VERSION" "$TARGET_VERSION"
RESULT=$?

case $RESULT in
  2)
    echo "VULNERABLE: Chrome $INSTALLED_VERSION is below $TARGET_VERSION"
    exit 1
    ;;
  0|1)
    echo "PATCHED: Chrome $INSTALLED_VERSION is at or above $TARGET_VERSION"
    exit 0
    ;;
  *)
    echo "UNKNOWN: Version comparison failed"
    exit 2
    ;;
esac

Sources

1. Google Chrome Stable Channel Update for Desktop (Chrome 149)
2. Chromium issue 502069297
3. CISA Known Exploited Vulnerabilities Catalog
4. FIRST EPSS API
5. FIRST EPSS documentation
6. CVE Alert snippet for CVE-2026-11283 description
7. Chrome security page