Insufficient validation of untrusted input in Chromoting in Google Chrome on Linux prior to 149

CVE-2026-11112 affects Google Chrome on Linux before 149.0.7827.53. The published CVE record says insufficient validation of untrusted input in Chromoting can let a remote attacker who has already compromised the renderer process potentially turn that foothold into a sandbox escape via a crafted Chrome Extension. That is an important distinction: this bug does not give an attacker first-hop code execution by itself; it is a post-compromise browser-escape primitive.

The supplied 9.6/CRITICAL rating overstates reality for enterprise prioritization. Google’s own June 2, 2026 Chrome stable advisory labels CVE-2026-11112 as Medium, and that tracks the real attack path much better because the decisive friction is the required prior renderer compromise, with extra narrowing from Linux-only scope and the crafted-extension condition. In practice this is a chain-enabler for targeted exploitation, not a fleet-wide emergency.

Why this verdict

• Start from Google's baseline, not the inflated 9.6: the official Chrome stable advisory classifies CVE-2026-11112 as Medium, which is more credible than a generic external CVSS score for a chained browser bug.
• Major downward adjustment for attacker position: the attacker must already have compromised the renderer process. That implies a prior exploit stage, so this is post-initial-access within the browser trust model.
• Further downward adjustment for population reach: this is Linux-only and references a crafted Chrome Extension, both of which materially reduce how many enterprise endpoints can be reached in real deployments.
• No urgency amplifier: no KEV listing, no public PoC found, and the supplied EPSS 0.00047 is extremely low.
• Not lower than MEDIUM because sandbox escape still matters: if an attacker already has a renderer foothold, escaping Chrome's sandbox is a meaningful step-up in real intrusion chains.

Why not higher?

If this were a direct webpage-to-host break with no prior compromise requirement, HIGH or CRITICAL would be justified. But the published description explicitly says the attacker must have already compromised the renderer, which sharply limits reachable victims and makes this a specialist exploit-chain component rather than a fleet-wide emergency.

Why not lower?

Sandbox escapes are strategically important because they defeat one of Chrome's core security boundaries. For high-value users on Linux, a private renderer exploit chained with this bug could still produce a serious endpoint compromise, so dismissing it as LOW would understate the risk.

1. Block unapproved extensions — Enforce Chrome enterprise policies that only allow sanctioned extensions and block sideloading or user-installed exceptions. Because this is a MEDIUM finding, there is no mitigation SLA — go straight to the 365-day remediation window, but this control is still the best way to reduce the specific exploit path while patching rolls through normal browser update rings.
2. Prioritize Linux browser inventory — Split Linux Chrome assets from Windows/macOS in your inventory and identify endpoints below 149.0.7827.53. There is no mitigation SLA — go straight to the 365-day remediation window for this severity, but you should know exactly which developer, admin, and internet-facing user populations are carrying the exposure.
3. Watch for Chrome child-process abuse — Tune EDR and behavioral analytics for Chrome spawning shells, script interpreters, package tools, or unexpected helpers on Linux. This will not prevent exploitation, but it gives you a practical backstop against the post-sandbox-escape phase during the normal remediation window.
4. Keep browser auto-update healthy — Validate that managed Linux systems can actually pull Chrome stable updates from your repo or vendor channel and are not pinned below 149.0.7827.53. For MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window, so the operational priority is preventing stranded versions.

Run this on the target Linux endpoint or through your fleet-management agent as a standard user; root is not required unless your environment restricts package queries. Save as check_cve_2026_11112.sh and run bash check_cve_2026_11112.sh; it checks installed Google Chrome version and returns VULNERABLE, PATCHED, or UNKNOWN.

#!/usr/bin/env bash
# check_cve_2026_11112.sh
# Detects whether Google Chrome on Linux is below 149.0.7827.53
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / not applicable / unable to determine

set -u

FIXED_VERSION="149.0.7827.53"
VERSION=""
SOURCE=""

ver_lt() {
  # returns 0 if $1 < $2
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" ]
}

extract_version() {
  echo "$1" | grep -Eo '[0-9]+(\.[0-9]+){3}' | head -n1
}

# Try executable paths first
for bin in google-chrome google-chrome-stable /opt/google/chrome/google-chrome; do
  if command -v "$bin" >/dev/null 2>&1; then
    OUT="$($bin --version 2>/dev/null || true)"
    VERSION="$(extract_version "$OUT")"
    SOURCE="$bin --version"
    [ -n "$VERSION" ] && break
  fi
done

# Try dpkg if still unknown
if [ -z "$VERSION" ] && command -v dpkg-query >/dev/null 2>&1; then
  OUT="$(dpkg-query -W -f='${Version}\n' google-chrome-stable 2>/dev/null || true)"
  VERSION="$(extract_version "$OUT")"
  SOURCE="dpkg-query google-chrome-stable"
fi

# Try rpm if still unknown
if [ -z "$VERSION" ] && command -v rpm >/dev/null 2>&1; then
  OUT="$(rpm -q --qf '%{VERSION}-%{RELEASE}\n' google-chrome-stable 2>/dev/null || true)"
  VERSION="$(extract_version "$OUT")"
  SOURCE="rpm -q google-chrome-stable"
fi

if [ -z "$VERSION" ]; then
  echo "UNKNOWN: Google Chrome on Linux not found or version could not be determined"
  exit 2
fi

if ver_lt "$VERSION" "$FIXED_VERSION"; then
  echo "VULNERABLE: Google Chrome version $VERSION is below fixed version $FIXED_VERSION ($SOURCE)"
  exit 1
else
  echo "PATCHED: Google Chrome version $VERSION is at or above fixed version $FIXED_VERSION ($SOURCE)"
  exit 0
fi

Sources

1. Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
2. Google Chrome Releases - 2026 archive
3. Chromium issue tracker entry 500541413
4. CIRCL Vulnerability-Lookup entry for CVE-2026-11112
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS overview
7. FIRST EPSS data and statistics
8. Chromium Security overview