CVE-2026-11158 · Google Chrome for macOS Downloads insufficient input validation…

01 · The Real Story

This is a spare key hidden under the mat after the burglar is already inside the house

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.

"High on paper, medium in practice: Mac-only, local-only, and post-initial-access keeps this out of the fire-drill queue"

02 · The Attack Path

4 steps from start to impact.

STEP 01

Land code on the Mac first

The attacker needs an initial foothold on the target Mac before Chrome even matters. In practice that means a malicious installer, a trojanized productivity app, a post-phish payload, or hands-on local access; the relevant weaponized tooling is whatever got them local execution, not the browser bug itself.

Conditions required:

Target is a macOS endpoint
Attacker can execute code locally or has hands-on access
Google Chrome is installed

Where this breaks in practice:

EDR, notarization controls, allowlisting, and MDM app controls often stop commodity Mac footholds before this stage
This prerequisite already implies post-initial-access, which sharply narrows the exposed population

Detection/coverage: Good coverage if you are watching for unsigned installers, suspicious .pkg/.dmg activity, LaunchAgent persistence, or unexpected user-space execution on managed Macs.

STEP 02

Drive input into Chrome Downloads

Once local, the attacker must interact with the vulnerable Downloads logic in Chrome versions below 149.0.7827.53 on macOS. The described payload path involves a crafted AppleScript command, so the exploit chain likely abuses download metadata or a download-handling edge case to influence an automation call from within Chrome.

Conditions required:

Chrome version is earlier than 149.0.7827.53
Browser is running on macOS
Attacker can feed crafted input into Chrome's download handling
Some user interaction occurs

Where this breaks in practice:

Bug details are still restricted, which usually slows reliable weaponization
User interaction is still required by the CVSS vector
A local attacker often has simpler ways to steal data than grooming a browser sandbox escape

Detection/coverage: Weak scanner coverage for the exploit path itself; strongest signal is version-based detection plus telemetry around unusual osascript/Apple Event activity spawned from Chrome.

STEP 03

Break out of the sandbox via AppleScript

If the crafted input lands correctly, the attacker may escape Chrome's sandbox and execute outside the browser boundary using macOS AppleScript tooling such as osascript or equivalent automation APIs. That matters because sandbox escape converts a constrained browser foothold into normal user-context execution on the host.

Conditions required:

Vulnerable Chrome build on macOS
Exploit path successfully reaches the AppleScript command construction/execution point
Chrome sandbox escape succeeds

Where this breaks in practice:

Modern macOS privacy prompts and TCC still limit access to some sensitive resources even after a sandbox escape
No evidence yet of broad in-the-wild exploit reliability

Detection/coverage: Hunt for child-process anomalies from Chrome, Apple Event abuse, osascript execution tied to browser activity, and unusual automation attempts immediately after download events.

STEP 04

Use user-context access for follow-on abuse

After escape, the attacker can operate in the logged-in user's context and go after browser data, files, session material, or persistence. The practical impact is host-level user compromise, not root compromise by default, so the blast radius is meaningful but still bounded to the endpoint and user account.

Conditions required:

Sandbox escape has already occurred
Attacker can act in the victim user's session

Where this breaks in practice:

Still limited to the rights of the logged-in user unless chained further
Enterprise EDR typically has strong visibility once the activity leaves the browser sandbox

Detection/coverage: High post-escape visibility if your EDR tracks browser-spawned processes, keychain access attempts, credential dumping behaviors, or unusual file access by Chrome-related processes.

03 · Compensating Control

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.

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.

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.

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.

What doesn't work

A WAF or perimeter IPS does not help; this is a local desktop browser issue, not a remotely exposed web service.
MFA does not stop a local sandbox escape. It protects identities, not browser-to-host boundary failures.
External attack-surface scanning is mostly irrelevant here because there is no internet-facing service to enumerate for this bug.

04 · Intelligence Metadata

The supporting signals.

In-the-wild status	No public evidence of active exploitation located, and the user-provided intel says `KEV listed: No`.
Proof-of-concept availability	No public PoC or exploit repository was found in open-source search results; the Chromium issue `501844153` is still access-restricted, which usually delays copycat exploitation.
EPSS	`0.00016` from the provided intel, which is effectively background noise for near-term exploitation probability; percentile was not verified from a primary EPSS record in the sources reviewed.
KEV status	Not present in the CISA KEV catalog as of this assessment window.
CVSS vector reality check	`CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H` translates to local attacker + user interaction + full impact if successful. That is dangerous on a single host, but it is not an internet-reachable first-hop enterprise event.
Affected versions	Google Chrome on macOS only before `149.0.7827.53`.
Fixed versions	Patch floor for this CVE is `149.0.7827.53` on macOS. Google's June 2, 2026 stable bulletin shipped `149.0.7827.53/54` for Windows/Mac and `149.0.7827.53` for Linux, but this specific flaw is described as Mac-only.
Scanning / exposure data	This is not meaningfully internet-scannable in the Shodan/Censys/FOFA sense because the bug lives in a local desktop browser workflow, not a remotely exposed network service. External exposure counts are therefore a poor prioritization signal.
Disclosure / reporting	Published `2026-06-04`. The official Chrome stable bulletin classifies `CVE-2026-11158` as Medium and notes it was reported by Google on 2026-04-12.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (4.8/10)

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.

06 · Verification

Crowdsourced verification payload.

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.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/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