← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11100 · CWE-416 · Disclosed 2026-06-04

Use after free in File Input in Google Chrome on Mac prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
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 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found in the sources reviewed, and not KEV-listed as of 2026-06-05.
Public PoC statusNo public PoC or exploit repo located for CVE-2026-11100 or Chromium issue 500416901; bug details appear restricted.
EPSS0.00035 from the supplied intel, which is very low and consistent with low observed exploitation pressure.
KEV statusNo. Not present in the CISA KEV catalog based on current review.
CVSS vector reality checkCVSS: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 versionsGoogle Chrome on Mac prior to 149.0.7827.53. This is not a Windows/Linux fleet problem for this CVE.
Fixed versionsFix 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 signalGoogle'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 realityNot 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 / reporterDisclosed 2026-06-04; Chrome release notes show it was reported by Google on 2026-04-07.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.3/10)

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.

HIGH Affected platform/version scope is limited to **Chrome on Mac before 149.0.7827.53**
MEDIUM Reassessed exploitability and urgency in real enterprise deployments

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
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
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: inventory your managed Mac Chrome population, identify anything below 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

  1. Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
  2. Google Chrome Releases - Early Stable Update for Desktop (May 29, 2026)
  3. Chromium issue 500416901 reference
  4. Tenable CVE record for CVE-2026-11100
  5. Vulnerability-Lookup entry for CVE-2026-11100
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS overview
  8. Google Chrome Help - Update Google Chrome
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.