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

CVE-2026-11158 is a Chrome for macOS bug in the Downloads component where untrusted input is not validated tightly enough before reaching an AppleScript execution path. On affected macOS systems running Google Chrome versions earlier than 149.0.7827.53, a local attacker can potentially turn crafted download-related input into a sandbox escape, moving from Chrome's containment boundary into code execution in the logged-in user's context.

The vendor-style 8.6/HIGH score overstates what most enterprise defenders should feel operationally. The decisive reality is the prerequisite stack: AV:L means the attacker is already on the Mac, UI:R means the user still has to do something, the bug is Mac-only, and there is no current exploitation signal, KEV listing, or public PoC; that is classic downward pressure from a fleet-prioritization perspective.

Why this verdict

• Local attacker prerequisite: AV:L is the big downgrade lever. If the attacker is already executing locally on the Mac, you are past initial compromise, so I cut hard from the 8.6 baseline.
• User interaction still required: UI:R adds another real-world gate. This is not a silent, wormable, or hands-off chain.
• Mac-only affected population: this excludes Windows and Linux fleets entirely. In mixed enterprises, that dramatically shrinks the reachable population.
• No exploitation signal: no KEV listing, no public PoC found, and EPSS is near-zero. That does not make it harmless, but it does keep it out of the top patch bucket.
• Sandbox escape still has teeth: once triggered, it can turn browser containment failure into user-context host compromise. That is why this is not LOW or IGNORE.

Why not higher?

It is not higher because the chain starts with the attacker already on the endpoint or physically at it. That prerequisite, plus UI:R, plus macOS-only scope, compounds into a much narrower real-world problem than the raw impact metrics suggest.

Why not lower?

It is not lower because sandbox escapes remain valuable to attackers who already have a low-priv foothold, especially on executive, developer, or research Macs with sensitive browser sessions. Even a local-only browser breakout can materially improve attacker tradecraft and access on a compromised host.

1. Enforce Chrome auto-update and relaunch — Use MDM or enterprise browser policy to make sure managed Macs move to 149.0.7827.53 or later and actually relaunch the browser so the fix is live. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but browsers are easy wins, so fold this into the next standard update wave rather than letting it linger.
2. Tighten local execution on Macs — Because this bug needs a local attacker first, the best compensating move is to reduce how often untrusted code can run at all: notarization enforcement, allowlisting, EDR prevention rules, and limiting unsanctioned .pkg/.dmg execution all directly cut the prerequisite. For MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window, but these controls should already be part of your standing Mac baseline.
3. Monitor AppleScript abuse from Chrome — Add or tune detections for Google Chrome spawning osascript, unusual Apple Events, or download-triggered automation behavior. This will not prevent the bug, but it gives you a practical tripwire for the most distinctive escape mechanism discussed in the advisory; for MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window.
4. Prioritize sensitive Mac cohorts — If you cannot update every Mac at once, move developer workstations, privileged admin Macs, and high-risk executive laptops to the front of the normal browser patch wave. For MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window, so use business-risk targeting rather than panic patching.

Run this on the target Mac endpoint locally, over SSH, or through your MDM remote shell. Invoke it with bash check_chrome_cve_2026_11158.sh; standard user rights are enough for the current user's app paths, and root lets it also inspect /Users/*/Applications for per-user installs.

#!/bin/bash
# check_chrome_cve_2026_11158.sh
# Detects whether Google Chrome on macOS is older than 149.0.7827.53
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN

set -u

FIXED_VERSION="149.0.7827.53"
PLISTBUDDY="/usr/libexec/PlistBuddy"

compare_versions() {
  # Returns:
  # 0 if equal
  # 1 if $1 > $2
  # 2 if $1 < $2
  local IFS='.'
  local i
  local -a a=($1)
  local -a b=($2)
  local len=${#a[@]}
  if [ ${#b[@]} -gt $len ]; then
    len=${#b[@]}
  fi
  for ((i=0; i<len; i++)); do
    local ai=${a[i]:-0}
    local bi=${b[i]:-0}
    if ((10#$ai > 10#$bi)); then
      return 1
    fi
    if ((10#$ai < 10#$bi)); then
      return 2
    fi
  done
  return 0
}

get_version() {
  local app_path="$1"
  local plist="$app_path/Contents/Info.plist"
  if [ -x "$PLISTBUDDY" ] && [ -f "$plist" ]; then
    "$PLISTBUDDY" -c 'Print :KSVersion' "$plist" 2>/dev/null && return 0
    "$PLISTBUDDY" -c 'Print :CFBundleShortVersionString' "$plist" 2>/dev/null && return 0
  fi
  return 1
}

paths=()
paths+=("/Applications/Google Chrome.app")
paths+=("$HOME/Applications/Google Chrome.app")

if [ "$(id -u)" -eq 0 ] && [ -d /Users ]; then
  while IFS= read -r -d '' p; do
    paths+=("$p")
  done < <(find /Users -maxdepth 2 -type d -name 'Google Chrome.app' -path '*/Applications/*' -print0 2>/dev/null)
fi

found=0
vulnerable=0
patched=0

seen=""
for app in "${paths[@]}"; do
  [ -d "$app" ] || continue

  case "|$seen|" in
    *"|$app|"*) continue ;;
    *) seen="$seen|$app" ;;
  esac

  version="$(get_version "$app")"
  if [ -z "$version" ]; then
    echo "UNKNOWN: Could not determine version for $app"
    continue
  fi

  found=1
  compare_versions "$version" "$FIXED_VERSION"
  rc=$?
  if [ $rc -eq 2 ]; then
    echo "VULNERABLE: $app -> $version (< $FIXED_VERSION)"
    vulnerable=1
  else
    echo "PATCHED: $app -> $version (>= $FIXED_VERSION)"
    patched=1
  fi
done

if [ $found -eq 0 ]; then
  echo "UNKNOWN: Google Chrome.app not found in checked locations"
  echo "UNKNOWN"
  exit 2
fi

if [ $vulnerable -eq 1 ]; then
  echo "VULNERABLE"
  exit 1
fi

if [ $patched -eq 1 ]; then
  echo "PATCHED"
  exit 0
fi

echo "UNKNOWN"
exit 2

Sources

1. Official CVE record in cvelistV5
2. Google Chrome Stable Channel Update for Desktop (June 2, 2026)
3. Chromium issue 501844153
4. FIRST EPSS data stats
5. CISA Known Exploited Vulnerabilities Catalog
6. Canadian Centre for Cyber Security advisory AV26-544
7. SecurityWeek coverage of Chrome 149 security fixes