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.
4 steps from start to impact.
Lure a Mac user into attacker-controlled web content
- 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
- 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
Induce the required file-input UI gestures
- User performs the required UI gesture sequence
- Page can present believable content that motivates the interaction
- 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
Trigger the File Input use-after-free on Mac
- The vulnerable code path is reachable on the target's Chrome build
- The exploit achieves reliable memory corruption on the target Mac
- 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
Convert memory corruption into sandbox escape impact
- Exploit chain is stable enough to cross the sandbox boundary
- Target defenses do not interrupt post-exploitation behavior
- 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
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. |
noisgate verdict.
The decisive downgrade factor is that exploitation requires a Mac target plus specific user UI gestures on a malicious page, which makes this materially less reachable and less automatable than the 9.6 score implies. With no KEV listing, no public exploitation evidence, and no public PoC, this looks like a serious but currently low-pressure client-side bug rather than an active fleet emergency.
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.
What to do — in priority order.
- 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.
- 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.
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.
#!/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
If you remember one thing.
149.0.7827.53, and fold those hosts into your normal browser maintenance lane rather than your emergency lane. Because this lands MEDIUM, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; use the noisgate remediation SLA to ensure every affected Mac is on 149.0.7827.53+ within 365 days, while cleaning up stale or unmanaged Chrome installs much sooner if that is low-friction in your environment.Sources
- Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
- Google Chrome Releases - Early Stable Update for Desktop (May 29, 2026)
- Chromium issue 500416901 reference
- Tenable CVE record for CVE-2026-11100
- Vulnerability-Lookup entry for CVE-2026-11100
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS overview
- Google Chrome Help - Update Google Chrome
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.