CVE-2026-11100 · Google Chrome for Mac File Input use-after-free with potential…

01 · The Real Story

This is a trapdoor in one hallway of one office, not the front door to the building

CVE-2026-11100 is a use-after-free in Chrome's File Input handling on macOS. The affected range is Google Chrome on Mac before 149.0.7827.53; the June 2, 2026 stable release shipped 149.0.7827.53/54 for Windows/Mac, but this CVE's description is explicitly Mac-specific. The bug requires a malicious page and specific user UI gestures against file input elements, after which memory corruption may let the attacker potentially perform a sandbox escape.

The 9.6/CRITICAL CVSS label overstates real enterprise urgency. In practice this is a client-side, Mac-only, user-driven bug with no public exploitation, no KEV listing, no public PoC, and even Google's own Chromium release stream tags it Medium, which is a strong signal that the attack path has real friction. Still worth fixing, because browser sandbox escapes are prized for post-renderer compromise chains, but this is not a drop-everything fleet event.

"Serious browser bug, but Mac-only plus required UI gestures and no exploitation evidence keep this out of emergency patching."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Lure a Mac user into attacker-controlled web content

The attacker needs to deliver a crafted HTML page to a Chrome user on macOS. In practice that means phishing, malvertising, compromised sites, or a redirect chain that gets the target into the hostile page. The weaponized tool here is just a custom HTML/JavaScript lure page; no public exploit kit is known.

Conditions required:

Target is using Google Chrome on macOS
Installed Chrome version is earlier than 149.0.7827.53
User browses to attacker-controlled or attacker-influenced content

Where this breaks in practice:

This is not server-side; the attacker gets nothing unless a user lands on the page
Windows and Linux fleets are irrelevant for this CVE
Web filtering, URL rewriting, and browser isolation can stop a meaningful slice of lures before execution

Detection/coverage: Good coverage from web proxies, SWG, DNS filtering, and phishing telemetry for the lure stage; poor vulnerability-specific signatures.

STEP 02

Induce the required file-input UI gestures

The bug does not appear to be a pure drive-by. The attacker must convince the user to perform specific UI gestures involving a file input control, such as clicking, dragging, or otherwise interacting with the picker workflow in a way that reaches the vulnerable path. That requirement sharply reduces automation and opportunistic exploitation.

Conditions required:

User performs the required UI gesture sequence
Page can present believable content that motivates the interaction

Where this breaks in practice:

Human interaction is mandatory and appears more specific than a normal click
Security awareness, anti-phishing UX, and suspicious-page breakage all reduce completion rates
Automated spraying at internet scale becomes much less reliable

Detection/coverage: Very limited direct detection. Browser telemetry may show anomalous renderer/browser crashes, but most scanners cannot validate gesture-dependent exploitability.

STEP 03

Trigger the File Input use-after-free on Mac

Once the user hits the vulnerable path, the crafted page attempts to trigger a use-after-free in File Input handling on macOS. The likely outcome is memory corruption in a privileged browser/UI path rather than a simple renderer-only issue, which is why the CVE mentions a potential sandbox escape.

Conditions required:

The vulnerable code path is reachable on the target's Chrome build
The exploit achieves reliable memory corruption on the target Mac

Where this breaks in practice:

Chrome exploit reliability is sensitive to build, allocator behavior, and macOS version details
Google often restricts bug details until the patch has broad uptake, so public weaponization lags
No public PoC or exploit repo was found

Detection/coverage: EDR may catch downstream abnormal child-process behavior or exploit-like crash chains, but static version checks are the primary detection method.

STEP 04

Convert memory corruption into sandbox escape impact

The attacker still has to turn the corruption into a meaningful sandbox escape. That is the payoff stage: escape from the normal web-content boundary and gain access beyond the renderer sandbox. No public evidence shows this has been operationalized in the wild.

Conditions required:

Exploit chain is stable enough to cross the sandbox boundary
Target defenses do not interrupt post-exploitation behavior

Where this breaks in practice:

Sandbox escapes are much harder to weaponize than renderer crashes
EDR, behavioral detections, and browser hardening raise the bar after corruption occurs
The CVE language says potentially perform a sandbox escape, which is weaker than demonstrated code execution

Detection/coverage: Post-exploit activity may be visible to EDR; pre-exploit network scanners will miss this entirely.

03 · Compensating Control

Restrict unmanaged browser exposure on Macs — Force managed Macs onto enrolled Chrome builds and block or flag stale unmanaged copies. Because this is a MEDIUM verdict, there is no mitigation SLA — go straight to the 365-day remediation window, but do this sooner if your Mac fleet has poor Chrome update hygiene.

Harden web delivery paths — Use SWG, DNS filtering, safe browsing enforcement, and phishing-resistant mail controls to reduce the chance users ever reach the malicious page that starts this chain. There is no noisgate mitigation SLA for MEDIUM, so treat this as opportunistic hardening while you remediate within 365 days.

Watch for crash spikes on Mac Chrome — Monitor EDR, browser crash telemetry, and helpdesk noise for unusual Chrome crashes or repeated failures around file selection flows on macOS. This will not prove exploitation, but it can surface risky stragglers while patch rollout proceeds inside the 365-day remediation window.

Prioritize high-risk Mac cohorts — Move internet-facing staff, executives, admins, and researchers to current Chrome first because they are the most likely lure targets. Even without a mitigation SLA, tightening those cohorts early cuts the highest-value exposure while standard remediation completes within 365 days.

What doesn't work

A network perimeter vuln scan will not help much; this is a client browser issue and is not meaningfully discoverable as an exposed internet service.
MFA does nothing for the exploit mechanics; it may reduce phishing account takeover, but it does not stop a user from loading a malicious page and interacting with a file input.
A generic WAF is largely irrelevant because the vulnerable code executes in the endpoint browser, not in your web application stack.

04 · Intelligence Metadata

The supporting signals.

In-the-wild status	No public exploitation evidence found in the sources reviewed, and not KEV-listed as of 2026-06-05.
Public PoC status	No public PoC or exploit repo located for `CVE-2026-11100` or Chromium issue `500416901`; bug details appear restricted.
EPSS	`0.00035` from the supplied intel, which is very low and consistent with low observed exploitation pressure.
KEV status	No. Not present in the CISA KEV catalog based on current review.
CVSS vector reality check	`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H` assumes the sandbox-escape path lands cleanly; the `UI:R` plus Mac-only scope are the main reasons the raw `9.6` inflates operational urgency.
Affected versions	Google Chrome on Mac prior to `149.0.7827.53`. This is not a Windows/Linux fleet problem for this CVE.
Fixed versions	Fix shipped in Chrome `149.0.7827.53` for Mac; Google's June 2, 2026 stable release lists `149.0.7827.53/54` for Windows/Mac.
Vendor vs scoring signal	Google's Chrome release labels this issue Medium, while external CVSS/NVD-style feeds show Critical 9.6. For prioritization, Google's own severity is the more believable operational signal here.
Exposure / scanning reality	Not Shodan/Censys/FOFA-scannable in any useful sense because this is endpoint browser client software, not an internet-facing service. Exposure equals the size of your managed Mac Chrome population, not your public attack surface.
Disclosure / reporter	Disclosed 2026-06-04; Chrome release notes show it was reported by Google on 2026-04-07.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (6.3/10)

Why this verdict

Downgrade: Mac-only target set reduces reachable population immediately versus a cross-platform Chrome bug.
Downgrade: user interaction is not generic; the attacker needs specific UI gestures around a file input, which is harder to mass-exploit than a passive page-load bug.
Downgrade: this is client-side, not internet-facing; it does not expose your perimeter or create unauthenticated remote reachability into enterprise infrastructure.
Downgrade: no exploitation pressure; no KEV listing, no public campaigns, and no public PoC were found.
Downgrade: vendor's own signal is weaker; Chromium classifies the issue as Medium, which usually reflects meaningful exploit-chain friction even when CVSS math goes high.
Upgrade pressure remains because a browser sandbox escape is strategically valuable if weaponized and Chrome is broadly deployed on user endpoints.

Why not higher?

To score this HIGH or CRITICAL, I would want either active exploitation, a public working exploit, or a substantially easier path than the advisory describes. Instead, the chain is narrowed by macOS-only applicability, required UI gestures, and the absence of evidence that attackers are successfully weaponizing it at scale.

Why not lower?

I would not bury this as LOW or IGNORE because use-after-free in a browser plus potential sandbox escape is still meaningful security debt on a high-value endpoint application. If an attacker already has a lure path into your Mac users, this bug could become a useful privilege-boundary break inside the browser.

06 · Verification

Crowdsourced verification payload.

Run this locally on each target Mac or through your Mac management agent. Invoke it as bash chrome_cve_2026_11100_check.sh "/Applications/Google Chrome.app"; no root is required if Chrome is installed in a readable location. It checks the installed Chrome version and prints VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/bin/bash
# Check Google Chrome on macOS for CVE-2026-11100 exposure
# Usage: bash chrome_cve_2026_11100_check.sh "/Applications/Google Chrome.app"
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / unable to determine

set -u

APP_PATH="${1:-/Applications/Google Chrome.app}"
REQUIRED_VERSION="149.0.7827.53"
PLIST_BUDDY="/usr/libexec/PlistBuddy"

version_ge() {
  # Returns 0 if $1 >= $2, else 1
  local IFS='.'
  local i
  local -a v1=($1) v2=($2)

  # Pad shorter array with zeros
  local len1=${#v1[@]}
  local len2=${#v2[@]}
  local maxlen=$(( len1 > len2 ? len1 : len2 ))

  for ((i=len1; i<maxlen; i++)); do v1[i]=0; done
  for ((i=len2; i<maxlen; i++)); do v2[i]=0; done

  for ((i=0; i<maxlen; i++)); do
    local a=${v1[i]}
    local b=${v2[i]}
    # force base-10 to avoid octal interpretation
    a=$((10#$a))
    b=$((10#$b))
    if (( a > b )); then return 0; fi
    if (( a < b )); then return 1; fi
  done
  return 0
}

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

INFO_PLIST="$APP_PATH/Contents/Info.plist"
if [[ ! -f "$INFO_PLIST" ]]; then
  echo "UNKNOWN - Info.plist not found at: $INFO_PLIST"
  exit 2
fi

VERSION=""
if [[ -x "$PLIST_BUDDY" ]]; then
  VERSION="$($PLIST_BUDDY -c 'Print :CFBundleShortVersionString' "$INFO_PLIST" 2>/dev/null || true)"
fi

if [[ -z "$VERSION" ]]; then
  VERSION="$(defaults read "$INFO_PLIST" CFBundleShortVersionString 2>/dev/null || true)"
fi

if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN - Could not determine Chrome version"
  exit 2
fi

if version_ge "$VERSION" "$REQUIRED_VERSION"; then
  echo "PATCHED - Installed Chrome version $VERSION is >= $REQUIRED_VERSION"
  exit 0
else
  echo "VULNERABLE - Installed Chrome version $VERSION is < $REQUIRED_VERSION"
  exit 1
fi