Inappropriate implementation in FileSystem in Google Chrome prior to 149

CVE-2026-11078 is a FileSystem input-validation flaw in Chrome before 149.0.7827.53. Google’s June 2, 2026 stable-channel notes place it in the Medium bucket and tie it to FileSystem; the user-supplied description adds the crucial context that the attacker must already have compromised the renderer. In plain English: this is not the bug that gets the attacker into Chrome in the first place — it is the bug that may let them do more *after* they already landed code or control in the renderer via some separate browser exploit.

The vendor’s MEDIUM 6.5 is directionally fair on paper, but operationally this lands lower than teams panic-patch for because the biggest friction point is brutal: it requires a prior renderer compromise. That means this CVE is post-initial-access inside the browser exploit chain, has no KEV listing, no stated in-the-wild exploitation, and a tiny EPSS. Ubiquitous product? Yes. Standalone enterprise emergency? No.

Why this verdict

• Major downward adjustment: requires prior renderer compromise. That implies the attacker is already past the hardest part of the browser kill chain, so CVE-2026-11078 is not your initial-access problem.
• User interaction remains required. The victim still has to browse to attacker-controlled content, which keeps email/web filtering and user-targeting friction in play.
• No KEV, no public exploit evidence, tiny EPSS. Without real-world burn signals, this does not justify emergency treatment across a 10,000-host fleet.
• External scanner visibility is weak, but exposure is broad. Chrome is everywhere, so you should patch it — just via normal fast browser hygiene, not incident-mode escalation.

Why not higher?

It is not higher because the attack path is compound: malicious content delivery, then a separate renderer compromise, then this FileSystem flaw. Every one of those prerequisites cuts the reachable victim pool and makes the CVE less actionable on its own than the raw integrity impact suggests.

Why not lower?

It is not lower because Chrome is a massively deployed client platform, and second-stage browser bugs still matter when they can strengthen exploit chains. Even without public exploitation, browser fleet hygiene matters, and this is still a real security fix in a ubiquitous app used on practically every endpoint.

1. Accelerate browser auto-update rings — Move Chrome to the front of your normal client-update cadence so vulnerable builds age out quickly. For a MEDIUM verdict there is no mitigation SLA, so use this as standard hygiene and complete remediation within the 365-day remediation window rather than treating it as a special emergency.
2. Enforce enterprise Chrome version compliance — Use MDM, EDR, or software inventory to identify endpoints below 149.0.7827.53 and push them through your standard browser remediation workflow. With no mitigation SLA, this is mainly about shrinking lingering legacy versions and getting to the fixed build within the 365-day remediation window.
3. Reduce risky browsing paths — Tighten web filtering, isolate unknown categories, and keep Safe Browsing or equivalent reputation controls enabled because the exploit chain still starts with hostile content delivery. This does not patch the bug, but it raises attacker cost while you remediate under the MEDIUM bucket’s no-mitigation-SLA model.
4. Watch for browser-to-host post-exploitation — Tune EDR to flag suspicious browser child processes, script interpreters launched by Chrome ancestry, odd file writes from the browser, and token abuse. That matters because the highest-value detection point is usually after a browser exploit chain lands, not during the restricted Chromium bug itself.

Run this on the target endpoint or through your fleet-management agent on Linux or macOS systems with Chrome/Chromium installed. Invoke it as bash check_chrome_cve_2026_11078.sh or push it remotely via your EDR/MDM shell runner; no root is required, but the script needs permission to execute the browser binary if present.

#!/usr/bin/env bash
# check_chrome_cve_2026_11078.sh
# Detect whether local Chrome/Chromium is older than 149.0.7827.53.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

MIN_VERSION="149.0.7827.53"
FOUND_VERSION=""
FOUND_BIN=""

candidates=(
  "google-chrome"
  "google-chrome-stable"
  "chromium"
  "chromium-browser"
  "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
  "/Applications/Chromium.app/Contents/MacOS/Chromium"
)

get_version() {
  local bin="$1"
  local out
  out="$($bin --version 2>/dev/null)" || return 1
  echo "$out" | grep -Eo '[0-9]+(\.[0-9]+){3}' | head -n1
}

version_lt() {
  # returns 0 if $1 < $2
  local IFS=.
  local i
  local -a a=($1)
  local -a b=($2)

  for ((i=${#a[@]}; i<4; i++)); do a[i]=0; done
  for ((i=${#b[@]}; i<4; i++)); do b[i]=0; done

  for i in 0 1 2 3; do
    if ((10#${a[i]} < 10#${b[i]})); then
      return 0
    elif ((10#${a[i]} > 10#${b[i]})); then
      return 1
    fi
  done
  return 1
}

for bin in "${candidates[@]}"; do
  if command -v "$bin" >/dev/null 2>&1; then
    ver="$(get_version "$bin")"
    if [[ -n "$ver" ]]; then
      FOUND_VERSION="$ver"
      FOUND_BIN="$bin"
      break
    fi
  elif [[ -x "$bin" ]]; then
    ver="$(get_version "$bin")"
    if [[ -n "$ver" ]]; then
      FOUND_VERSION="$ver"
      FOUND_BIN="$bin"
      break
    fi
  fi
done

if [[ -z "$FOUND_VERSION" ]]; then
  echo "UNKNOWN - Chrome/Chromium not found or version unreadable"
  exit 2
fi

if version_lt "$FOUND_VERSION" "$MIN_VERSION"; then
  echo "VULNERABLE - $FOUND_BIN version $FOUND_VERSION is older than $MIN_VERSION"
  exit 1
else
  echo "PATCHED - $FOUND_BIN version $FOUND_VERSION meets or exceeds $MIN_VERSION"
  exit 0
fi

Sources

1. Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
2. Chromium issue tracker entry 499917177
3. Chromium Security project page
4. GovCERT.HK advisory for Chrome 149.0.7827.53
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS API
7. CVE record
8. NVD record