Inappropriate implementation in Chromoting in Google Chrome on Linux prior to 149

CVE-2026-11170 is an *inappropriate implementation* flaw in Chrome's Chromoting component on Linux builds prior to 149.0.7827.53. Google listed it in the June 2, 2026 Stable Channel release, and your supplied metadata pegs it to CWE-693 with a vendor HIGH 8.1 vector of AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Public bug details are still restricted, so the exact trigger is not public; what is public is the scope: Linux-only, Chrome-only, and specifically the Chromoting code path.

The vendor score is aggressive for fleet prioritization. In a vacuum, unauthenticated network reach plus OS-level impact deserves attention, but in enterprise reality this is *not* a generic renderer RCE hitting every browser session equally: it is Linux-only, tied to a narrower component, marked high complexity, has no KEV entry, no confirmed in-the-wild exploitation, and no public weaponized PoC I could verify. For a 10,000-host shop, that makes this a MEDIUM operational risk unless your environment has a heavy Linux desktop population using Chrome features that exercise Chromoting.

Why this verdict

• Linux-only scope cuts population hard: this is not a whole-fleet Chrome emergency unless you actually run a meaningful Linux desktop estate.
• Chromoting is narrower than the generic web renderer: the public record places the bug in a specific component, which implies fewer real sessions can hit it than a broad renderer or V8 issue.
• High attack complexity matters: AC:H plus restricted bug details and no PoC means the path from advisory text to reliable weaponization is not short.
• No exploitation evidence: no KEV entry, no verified campaigns, and no public exploit code means there is no current attacker-pressure multiplier pushing this upward.
• Browser-client exposure is not internet-enumerable: you cannot justify emergency treatment from Shodan-style exposure because this is an endpoint/browser maintenance problem, not a server perimeter problem.

Why not higher?

If this were a cross-platform renderer or V8 issue with public exploit code, I would keep it high. But Linux-only scope, component-specific reachability, and AC:H compound each other and materially reduce the number of real enterprise systems an attacker can hit and reliably compromise.

Why not lower?

I am not calling this LOW because the *technical* impact is still serious if the chain works: remote, unauthenticated, and potentially host-impacting. A Linux-heavy engineering estate or remote-admin-heavy workflows could make this matter more than the average enterprise baseline.

1. Constrain Linux Chrome rollout channels — Force managed Linux endpoints onto the patched browser build and stop exceptions or pinned legacy versions. There is no mitigation SLA for a MEDIUM verdict; use this immediately where practical and close remaining drift inside the 365-day remediation window.
2. Tighten Linux endpoint EDR detections — Add or verify detections for Chrome spawning shells, interpreters, package managers, or unusual child processes on Linux. There is no mitigation SLA for a MEDIUM verdict; deploy as standard hardening while you work through browser patching.
3. Reduce risky browser feature usage on Linux admin workstations — Where operationally possible, minimize optional remote-control/browser-assisted admin workflows that could exercise Chromoting on privileged Linux endpoints. There is no mitigation SLA for a MEDIUM verdict; apply selectively to high-value admin tiers until patch coverage is complete.
4. Isolate high-value Linux desktop tiers — Keep engineering jump hosts, admin workstations, and developer Linux desktops segmented so a user-context browser compromise has less lateral payoff. There is no mitigation SLA for a MEDIUM verdict; this is a risk-reduction layer, not a substitute for patching.

Run this on the target Linux endpoint or through your remote shell/management agent. Invoke it as bash check_chrome_11170.sh; no root is required if Chrome is in the user's PATH, but root may help if you need to inspect system package locations. The script checks common Chrome/Chromium binaries and reports VULNERABLE, PATCHED, or UNKNOWN against fixed version 149.0.7827.53.

#!/usr/bin/env bash
# check_chrome_11170.sh
# Detects whether a Linux host appears vulnerable to CVE-2026-11170 based on browser version.
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / unable to determine

set -u

FIXED_VERSION="149.0.7827.53"
CANDIDATES=(
  google-chrome
  google-chrome-stable
  chromium
  chromium-browser
  /opt/google/chrome/chrome
  /usr/bin/google-chrome
  /usr/bin/google-chrome-stable
  /usr/bin/chromium
  /usr/bin/chromium-browser
)

found_bin=""
found_ver=""

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

get_version() {
  local bin="$1"
  local out
  out="$($bin --version 2>/dev/null || true)"
  # Examples:
  # Google Chrome 149.0.7827.53
  # Chromium 149.0.7827.53 snap
  printf '%s' "$out" | grep -Eo '[0-9]+(\.[0-9]+){3}' | head -n1
}

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

if [ -z "$found_bin" ] || [ -z "$found_ver" ]; then
  echo "UNKNOWN: could not find a Chrome/Chromium binary or parse its version"
  exit 2
fi

if version_lt "$found_ver" "$FIXED_VERSION"; then
  echo "VULNERABLE: $found_bin version $found_ver is older than fixed version $FIXED_VERSION"
  exit 1
else
  echo "PATCHED: $found_bin version $found_ver is at or newer than fixed version $FIXED_VERSION"
  exit 0
fi

Sources

1. Google Chrome Stable Channel Update for Desktop (June 2, 2026)
2. Chromium issue reference for CVE-2026-11170
3. Chrome early stable rollout explanation
4. Chromium severity guidelines
5. Chromium security overview
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS overview
8. Public CVE aggregator snapshot for CVE-2026-11170