CVE-2026-11112 · Chrome Chromoting Input Validation Sandbox Escape on Linux

01 · The Real Story

A second-floor window left unlatched, but you still need to break through the front door to reach it

CVE-2026-11112 is an input-validation flaw in Chromoting (Google's Chrome Remote Desktop protocol stack) within Google Chrome on Linux only, affecting all versions prior to 149.0.7827.53. The vulnerability sits at the boundary between the sandboxed renderer process and the higher-privileged browser/host process. A crafted Chrome Extension can feed malformed data through Chromoting IPC channels that the browser process trusts without re-validation — a classic CWE-501 trust-boundary violation. If successfully exploited, an attacker escapes the Chrome sandbox and gains code execution with the privileges of the Chrome browser process (typically the logged-in user). The secondary CWE is CWE-20 (Improper Input Validation).

The vendor CVSS of 9.6 Critical dramatically overstates the real-world risk because the score treats this as a standalone vulnerability. It is not. The description explicitly states the attacker must have *already compromised the renderer process* — meaning a separate, unchained exploit (e.g., a V8 or Blink memory-corruption bug) is a hard prerequisite. Google's own Chromium security team rated this Medium severity internally, and Ubuntu triaged it as Medium priority. The EPSS score of 0.22% (12th percentile) confirms the exploit-prediction community agrees this is low-probability. There is no known in-the-wild exploitation, no CISA KEV listing, and no public proof-of-concept. The CVSS score is a textbook example of why raw CVSS without chain-awareness misleads patch prioritization.

"Sandbox escape that needs a sandbox breach first — Google themselves call it Medium"

02 · The Attack Path

4 steps from start to impact.

STEP 01

Renderer compromise via separate vulnerability

The attacker must first achieve code execution inside Chrome's sandboxed renderer process. This requires exploiting a *different* vulnerability — typically a V8 JIT bug, a Blink use-after-free, or a WebAssembly type-confusion. These are high-value exploits that sell for $100K+ on the bug-bounty and gray markets. The attacker delivers this via a malicious or compromised webpage the victim visits.

Conditions required:

Victim visits attacker-controlled or compromised webpage
A separate renderer RCE vulnerability (0-day or unpatched N-day) exists and is weaponized
Chrome on Linux is the target browser

Where this breaks in practice:

Chrome renderer exploits are rare and expensive; V8 mitigations (sandbox, CFI, MTE on supported hardware) raise the bar significantly
Chrome auto-updates on most managed Linux desktops, shrinking the N-day window
Enterprise web proxies and DNS filtering reduce exposure to attacker-controlled domains

Detection/coverage: Renderer crashes generate crash reports in chrome://crashes. EDR agents with browser exploit detection (CrowdStrike Falcon, SentinelOne) flag anomalous renderer behavior. Chrome's CrashPad telemetry can be centrally monitored.

STEP 02

Craft and load malicious Chrome Extension

With renderer code execution, the attacker must deliver a crafted Chrome Extension that exercises the Chromoting IPC pathway. The extension injects malformed messages into the Chromoting host communication channel, exploiting the missing input validation on the browser-process side. The extension may be sideloaded or injected into an existing extension's context.

Conditions required:

Renderer process is already compromised (Step 1 succeeded)
Chromoting/Chrome Remote Desktop component is installed and active on the target
Extension installation is not blocked by enterprise policy

Where this breaks in practice:

Enterprise Chrome deployments commonly enforce ExtensionInstallBlocklist with a wildcard (*) and use ExtensionInstallAllowlist for approved extensions only, blocking arbitrary sideloading
Chrome Remote Desktop usage on Linux endpoints is a minority use case — most enterprises use dedicated RMM tools (e.g., SCCM, Tanium, Ansible) for Linux fleet management
The attacker must know or discover that Chromoting is active on this specific host

Detection/coverage: Chrome enterprise reporting logs extension installs centrally. chrome.management API events can be forwarded to SIEM. EDR agents flag unsigned or sideloaded extension loads.

STEP 03

Trigger trust-boundary violation in Chromoting IPC

The malicious extension sends specially crafted messages through the Chromoting IPC channel that cross from the sandboxed renderer context into the privileged browser process. Because the browser process does not re-validate the input from what it assumes is a trusted internal channel, the attacker's payload is processed with elevated privilege. This constitutes the sandbox escape.

Conditions required:

Malicious extension is loaded and running (Step 2 succeeded)
Chromoting IPC channel is active (Chrome Remote Desktop session or service is running)

Where this breaks in practice:

The Chromoting host service must be actively running — it does not start by default on most Linux installations; the user must have explicitly set up Chrome Remote Desktop
The IPC message format must be precisely crafted to trigger the validation gap without crashing the browser process

Detection/coverage: Browser-process crashes or unexpected child-process spawns are detectable by EDR. Linux audit logs (auditd) can flag unexpected process trees originating from Chrome.

STEP 04

Code execution as the local user

Upon successful sandbox escape, the attacker gains code execution with the privileges of the Chrome browser process — typically the logged-in desktop user on Linux. From here, standard post-exploitation follows: credential harvesting (SSH keys, browser-stored passwords, GNOME Keyring), lateral movement via SSH, and persistence via cron or systemd user units.

Conditions required:

Sandbox escape succeeded (Step 3)
Target host has valuable assets or network access

Where this breaks in practice:

Code execution is limited to user-level privileges unless a separate local privilege escalation is chained
Linux desktop endpoints in enterprises are typically lower-value targets than servers or domain controllers
SELinux/AppArmor policies on the Chrome process may further contain the escaped process

Detection/coverage: EDR detects post-exploitation activity (credential access, lateral movement). Linux auditd rules for suspicious process ancestry from Chrome. Network IDS flags unusual outbound connections from workstation endpoints.

03 · Compensating Control

MEDIUM 5.5→IGNORE 0.0

SEVERITY REDUCED

Update Chrome to 149.0.7827.53 or later — The definitive fix. Chrome's auto-update mechanism handles this on most managed Linux desktops. Verify via google-chrome --version or chromium-browser --version. For enterprises using the Chrome stable channel on Linux, confirm update policies are not blocking the 149.x rollout. No mitigation SLA applies for MEDIUM — go straight to the 365-day remediation window per noisgate remediation SLA, though Chrome auto-update should have resolved this months ago.

MEDIUM 5.5→LOW 2.5

SEVERITY REDUCED

Enforce extension allowlist policy — Set ExtensionInstallBlocklist to * (block all) and use ExtensionInstallAllowlist to permit only approved extensions. This breaks Step 2 of the attack chain by preventing the attacker from loading a malicious extension even with renderer compromise. Deploy via Chrome Enterprise policy on Linux (/etc/opt/chrome/policies/managed/). No mitigation SLA for MEDIUM.

MEDIUM 5.5→LOW 2.0

SEVERITY REDUCED

Disable Chrome Remote Desktop on non-required endpoints — Remove or disable the Chrome Remote Desktop host package (chrome-remote-desktop) on Linux endpoints that don't need it. This eliminates the Chromoting IPC channel entirely, breaking Step 3. Use configuration management (Ansible/Puppet/Chef) to enforce: sudo apt remove chrome-remote-desktop or equivalent. No mitigation SLA for MEDIUM.

MEDIUM 5.5→MEDIUM 4.5

Deploy browser-aware EDR with exploit detection — EDR agents that monitor Chrome process trees (CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint on Linux) can detect renderer exploitation artifacts and anomalous sandbox-escape behavior. This provides detection-in-depth for both Step 1 and Step 4 of the attack chain. No mitigation SLA for MEDIUM.

What doesn't work

Network-level controls (WAF, IDS, firewall rules) — The initial attack vector is a standard HTTPS webpage visit. The sandbox escape occurs entirely within local Chrome IPC. Network controls cannot inspect or block either stage.
Disabling JavaScript — While this might hinder some renderer exploits (Step 1), it is not practical for enterprise users and does not address the Chromoting IPC validation flaw itself.
Chrome Site Isolation — Site Isolation protects against cross-origin data leaks but does not prevent a renderer exploit from escalating through Chromoting IPC to escape the sandbox.

04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitation	None observed. Not listed in CISA KEV. No reports from Google TAG, Mandiant, or other threat-intelligence vendors of active exploitation. Google's advisory contains no "reported as exploited" language.
Proof-of-concept availability	No public PoC found. Checked pocindex.io, GitHub (no repos named CVE-2026-11112), ExploitDB, and Nuclei templates — all negative. The Chromium bug (issues.chromium.org/issues/500541413) is access-restricted, typical of Chromium security bugs.
EPSS score	0.00216 (0.22%) — 12th percentile. The exploit-prediction model considers this vulnerability unlikely to be exploited in the next 30 days.
KEV status	Not listed as of 2026-09-30. No known exploitation by ransomware groups or APTs.
CVSS vector interpretation	`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H` — The S:C (Scope Changed) drives the 9.6 score, reflecting sandbox escape. However, the vector does not account for the chained prerequisite of renderer compromise, which makes AC:L misleading. Google's own Chromium security team rated this Medium.
Affected versions	Google Chrome on Linux only, all versions prior to `149.0.7827.53`. Windows and macOS are not affected. Ubuntu notes the snap-packaged `chromium-browser` auto-updates and marks all supported releases as not affected.
Fixed versions	`149.0.7827.53` (Linux stable channel, released 2026-06-04). Debian and Fedora Chromium packages track upstream; Ubuntu's snap auto-updates. No backports needed — Chrome's rolling release model means the fix is the latest stable.
Scanning / exposure data	Chrome Remote Desktop uses outbound HTTPS/WebRTC to Google's relay infrastructure — it does not expose a listening port. Shodan/Censys/GreyNoise scans are not applicable for discovering vulnerable endpoints. Vulnerability scanners must check the local Chrome binary version.
Disclosure timeline	Disclosed 2026-06-04 in Chrome 149 stable channel update. Last modified 2026-07-23. Part of a record 429-vulnerability Chrome release.
Reporting researcher	Not publicly credited. The Chromium bug tracker entry is access-restricted. No bug-bounty amount disclosed for this specific CVE.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (5.5/10)

Why this verdict

Chained prerequisite eliminates standalone exploitability. The vulnerability *cannot* be exploited without first compromising the Chrome renderer process via a separate, unrelated vulnerability. This transforms the real-world attack complexity from AC:L to effectively AC:H, requiring two independent exploits chained together. This alone warrants a 2–3 point reduction from the base score.
Google's own team rated this Medium. The Chromium security team — who wrote the code, reviewed the bug, and understand the exploitation constraints — assigned Medium severity. Ubuntu independently concurred with Medium priority. When the vendor's internal assessment diverges this sharply from the CVSS score (Medium vs. 9.6 Critical), the vendor's judgment carries significant weight for practitioners.
Linux-only plus Chromoting-active narrows the target population dramatically. Linux desktop represents ~4% of the desktop OS market. Of those running Chrome on Linux, only a small fraction have Chrome Remote Desktop actively configured. Conservative estimate: <2% of the Chrome installed base is reachable by this specific vulnerability.
No exploitation evidence or tooling exists. Zero PoCs, zero KEV listing, zero ITW reports, EPSS at the 12th percentile. Four months post-disclosure, nobody has weaponized this — consistent with the high cost of the renderer-compromise prerequisite.
Role multiplier: Chrome on Linux is predominantly a *workstation* browser. It is not canonically deployed as identity infrastructure, a hypervisor, a network edge appliance, or a CI/CD controller. Chromoting specifically requires an interactive desktop session, ruling out headless-Chrome CI/CD scenarios. The worst plausible high-value role is a developer workstation with SSH keys or cloud credentials — the blast radius is host-level, not domain/fleet/supply-chain. This does not trigger the HIGH floor because the affected component is not a high-value-role component by definition (<10% of installs occupy a high-value role).

Why not higher?

Elevating to HIGH would require either active exploitation evidence, a public PoC that lowers the barrier, or the affected component being canonically deployed in a high-value infrastructure role. None of these conditions are met. The renderer-compromise prerequisite makes this a second-stage exploit that cannot be triggered independently — it is materially different from a standalone sandbox escape reachable via a single malicious page.

Why not lower?

Dropping to LOW would understate the *consequence* of successful exploitation: a sandbox escape is a serious primitive that converts browser-context access into OS-level code execution. If an attacker already possesses a renderer exploit (as state-sponsored actors do), this CVE provides a clean, low-complexity second stage. The Scope Changed (S:C) impact is real — the trust boundary violation crosses a meaningful security boundary. MEDIUM correctly balances the high consequence against the high prerequisite bar.

06 · Verification

Crowdsourced verification payload.

Run this script on each target Linux host where Chrome is installed. It requires no special privileges — any user can execute it. Invoke with: bash check_cve_2026_11112.sh. The script checks the installed Chrome/Chromium version and whether the Chrome Remote Desktop host is installed.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check_cve_2026_11112.sh
# Checks for CVE-2026-11112: Chromoting input validation sandbox escape
# Affected: Google Chrome on Linux < 149.0.7827.53
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

FIXED_MAJOR=149
FIXED_MINOR=0
FIXED_BUILD=7827
FIXED_PATCH=53

# Detect Chrome binary
CHROME_BIN=""
for candidate in google-chrome google-chrome-stable chromium-browser chromium; do
  if command -v "$candidate" &>/dev/null; then
    CHROME_BIN="$candidate"
    break
  fi
done

if [[ -z "$CHROME_BIN" ]]; then
  echo "UNKNOWN — No Chrome or Chromium binary found on this host."
  exit 2
fi

# Get version
VERSION_STRING=$($CHROME_BIN --version 2>/dev/null | grep -oP '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+')
if [[ -z "$VERSION_STRING" ]]; then
  echo "UNKNOWN — Could not determine Chrome version from $CHROME_BIN."
  exit 2
fi

IFS='.' read -r MAJ MIN BLD PAT <<< "$VERSION_STRING"

# Check if Chromoting/Chrome Remote Desktop host is installed
CRD_INSTALLED=false
if dpkg -l chrome-remote-desktop 2>/dev/null | grep -q '^ii'; then
  CRD_INSTALLED=true
elif rpm -q chrome-remote-desktop &>/dev/null; then
  CRD_INSTALLED=true
fi

# Version comparison
VULNERABLE=false
if (( MAJ < FIXED_MAJOR )); then
  VULNERABLE=true
elif (( MAJ == FIXED_MAJOR && MIN < FIXED_MINOR )); then
  VULNERABLE=true
elif (( MAJ == FIXED_MAJOR && MIN == FIXED_MINOR && BLD < FIXED_BUILD )); then
  VULNERABLE=true
elif (( MAJ == FIXED_MAJOR && MIN == FIXED_MINOR && BLD == FIXED_BUILD && PAT < FIXED_PATCH )); then
  VULNERABLE=true
fi

echo "Chrome binary:    $CHROME_BIN"
echo "Installed version: $VERSION_STRING"
echo "Fixed version:     $FIXED_MAJOR.$FIXED_MINOR.$FIXED_BUILD.$FIXED_PATCH"
echo "CRD host installed: $CRD_INSTALLED"
echo ""

if [[ "$VULNERABLE" == true ]]; then
  if [[ "$CRD_INSTALLED" == true ]]; then
    echo "VULNERABLE — Chrome $VERSION_STRING is below the fix AND Chrome Remote Desktop is installed. Full attack surface is present."
  else
    echo "VULNERABLE — Chrome $VERSION_STRING is below the fix, but Chrome Remote Desktop host is NOT installed (Chromoting IPC surface may be reduced)."
  fi
  exit 1
else
  echo "PATCHED — Chrome $VERSION_STRING is at or above the fixed version."
  exit 0
fi