CVE-2026-11116 · Use-After-Free in Chromoting (Chrome Remote Desktop) Packet Handler

01 · The Real Story

It's like finding a lockpicking vulnerability on a side door that 95% of tenants have bricked shut

CVE-2026-11116 is a use-after-free (CWE-416 / CWE-825) in Chromoting, the protocol engine behind Chrome Remote Desktop. A remote attacker who can inject crafted STUN or TURN signaling packets into an active Chromoting session can trigger a dangling-pointer dereference, potentially achieving code execution at the privilege level of the Chrome process. All desktop platforms (Windows, macOS, Linux) running Google Chrome versions prior to 149.0.7827.53 are affected. The fix landed in the Chrome 149 stable release on June 4, 2026, alongside 428 other patches in a record-breaking security update.

The NVD CVSS score of 8.8 HIGH significantly overstates real-world risk here, and Google's own Chromium security team agrees — they classified this as Medium severity. The CVSS vector (AV:N/AC:L/PR:N/UI:R) treats the attack as trivially reachable over the network, but it ignores a critical precondition: the victim must be *actively running a Chrome Remote Desktop session* for the Chromoting code paths to be reachable at all. Chrome Remote Desktop is an optional, opt-in feature with modest enterprise adoption compared to dedicated RDP, VDI, or commercial remote access tools. The SSVC assessment — exploitation: none, automatable: no — further confirms this is not a weaponization-ready bug. With an EPSS of 0.29% (21st percentile), no public PoC, no KEV listing, and Chrome's aggressive auto-update pipeline, the 8.8 label is a paper tiger.

"Chromoting UAF is vendor-Medium for a reason: optional feature, no PoC, no exploitation, auto-patched."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Victim activates Chrome Remote Desktop

The target user must have Chrome Remote Desktop installed and actively running a session (either hosting or connecting). Chromoting code paths — including the vulnerable STUN/TURN packet handler — are only loaded when CRD is actively in use. Without an active session, the vulnerable code is never reached.

Conditions required:

Chrome Remote Desktop extension installed and configured
Active CRD session in progress

Where this breaks in practice:

Chrome Remote Desktop is an opt-in feature, not enabled by default
Enterprise environments overwhelmingly use dedicated remote access (Citrix, VMware Horizon, RDP) rather than CRD
Many enterprises block CRD via Chrome policy (RemoteAccessHostClientDomainList or outright disable)

Detection/coverage: Chrome enterprise management logs CRD session activity; policy audit for RemoteAccessHostFirewallTraversal and RemoteAccessHostClientDomainList

STEP 02

Attacker positions on the signaling/relay path

The attacker must be able to inject crafted STUN or TURN signaling packets into the active Chromoting session. In a typical CRD deployment, STUN/TURN traffic traverses Google's relay infrastructure. The attacker needs to either compromise the relay path, perform a network-level MITM between the victim and Google's STUN/TURN servers, or already be an authenticated peer in the session.

Conditions required:

Network position to inject packets on the STUN/TURN signaling path
Ability to craft valid-looking signaling packets that reach the Chromoting parser

Where this breaks in practice:

Google's relay infrastructure uses TLS; MITM requires compromising the relay or having a privileged network position
NAT traversal packets are session-specific — blind injection from the internet is non-trivial
Enterprise egress firewalls and proxies limit STUN/TURN traffic visibility

Detection/coverage: Network IDS/IPS signatures for anomalous STUN/TURN traffic patterns; TLS inspection at egress proxy

STEP 03

Trigger the use-after-free

The attacker sends a crafted series of signaling packets designed to trigger premature object deletion in the Chromoting packet-handling code. The freed memory is then reallocated with attacker-controlled content via heap spray techniques, typically using JavaScript arrays within the browser's renderer process.

Conditions required:

Precise knowledge of the heap layout and object lifecycle in the target Chrome version
Packets must arrive during a specific window in the session handshake

Where this breaks in practice:

No public PoC exists — the heap manipulation details are not publicly documented
Chrome's PartitionAlloc heap allocator includes significant UAF mitigations (MiraclePtr/BackupRefPtr) that make reliable exploitation difficult
ASLR, CFI, and V8 sandbox further raise the exploitation bar

Detection/coverage: Chrome crash reports and chrome://crashes telemetry; EDR behavioral detection for anomalous Chrome child process spawning

STEP 04

Achieve code execution at user privilege level

If the heap spray succeeds and the dangling pointer is dereferenced with attacker-controlled data, the attacker gains code execution within the Chrome browser process at the privilege level of the logged-in user. This is not SYSTEM/root — it's the user's privilege level, further constrained by Chrome's sandbox if the affected code runs in a sandboxed process.

Conditions required:

Successful heap grooming past PartitionAlloc mitigations
Bypassing Chrome sandbox if the Chromoting code runs in a sandboxed context

Where this breaks in practice:

Chrome's multi-process sandbox architecture limits what a compromised renderer can do
PartitionAlloc's MiraclePtr has been shown to block >50% of UAF exploitation attempts in Chromium
Privilege escalation from user-level to SYSTEM/root requires a separate exploit chain

Detection/coverage: EDR detection of suspicious process behavior originating from chrome.exe; application allowlisting blocking unexpected child processes

03 · Compensating Control

MEDIUM 5.5→IGNORE 0.0

SEVERITY REDUCED

Disable Chrome Remote Desktop via enterprise policy — Set RemoteAccessHostFirewallTraversal to Disabled and RemoteAccessHostClientDomainList to an empty list via GPO, Intune, or Chrome Browser Cloud Management. This completely eliminates the Chromoting attack surface. Deploy within the noisgate remediation SLA of 365 days for MEDIUM severity, though this is a quick win that most enterprises should have already done if CRD is not sanctioned.

MEDIUM 5.5→IGNORE 0.0

SEVERITY REDUCED

Ensure Chrome auto-update is functioning — Verify that Chrome's auto-update mechanism (Google Update / Omaha on Windows, system package manager on Linux) is operational and not blocked by proxy or firewall rules. Chrome 149.0.7827.53 has been available since June 4, 2026. Run chrome://settings/help audits across the fleet. No mitigation SLA applies for MEDIUM — go straight to confirming patch deployment within the 365-day remediation window.

MEDIUM 5.5→LOW 2.5

SEVERITY REDUCED

Block STUN/TURN traffic at the perimeter for unauthorized apps — If Chrome Remote Desktop is not sanctioned, block outbound UDP 3478/TCP 443 to Google's STUN/TURN relay ranges (stun.l.google.com, relay.webrtc.org) at the enterprise firewall or proxy. This prevents Chromoting from establishing relay connections even if the extension is installed. Note this may impact sanctioned WebRTC applications — test before deploying broadly.

MEDIUM 5.5→MEDIUM 4.5

Deploy EDR with browser exploit detection — Modern EDR solutions (CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne) detect anomalous behavior from browser processes including unexpected child process creation, shellcode injection, and heap spray artifacts. Ensure Chrome is covered by behavioral detection policies. This does not prevent exploitation but catches post-exploitation activity.

What doesn't work

Network segmentation alone — Chromoting uses Google's cloud relay infrastructure over standard HTTPS (TCP 443), so segmenting internal VLANs does not prevent the attack vector, which traverses the internet.
Chrome Site Isolation — Site Isolation separates renderer processes per origin but does not apply to the Chromoting signaling handler, which operates in the browser process, not a renderer.
WAF rules — Chromoting traffic is not HTTP-based web application traffic; it uses STUN/TURN protocols. A traditional WAF will not see or filter this traffic.

04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitation	None observed. Not listed on CISA KEV. No campaigns attributed. SSVC assessment: exploitation none, not automatable. GreyNoise shows no scanning activity targeting Chromoting specifically.
Proof-of-concept	No public PoC found. Checked pocindex.io, GitHub (`site:github.com CVE-2026-11116`), ExploitDB, SecureWithUmer/CVE-2026-PoCs — no dedicated repositories or exploit code. The Chromium bug (#501376612) is access-restricted.
EPSS	0.00288 (0.29%) — 21st percentile. Indicates very low predicted probability of exploitation in the next 30 days.
KEV status	Not listed. No CISA KEV entry as of 2026-09-30.
CVSS vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H` — 8.8 HIGH per NVD. Chromium security severity: Medium. The divergence reflects Chromium's assessment that real-world exploitability is significantly lower than the base vector suggests.
Affected versions	Google Chrome < 149.0.7827.53 on Windows, macOS, and Linux desktop. Chromium-based browsers (Edge, Brave, Vivaldi) may be affected if they ship Chromoting code.
Fixed versions	Chrome 149.0.7827.53+ (stable channel, June 4, 2026). Debian: DSA-6325-1. Other distros: check chromium-browser package versions ≥ 149.0.7827.53.
Scanning/exposure	Chromoting uses Google's relay infrastructure (STUN/TURN); it is not a directly Shodan-enumerable service. No mass-scanning activity detected on GreyNoise for Chromoting-related traffic.
Disclosure timeline	Disclosed 2026-06-04 as part of Chrome 149 stable release (429 CVEs patched). Updated 2026-06-08. Chromium bug #501376612 remains restricted.
Reporter	Not publicly credited. The Chromium bug tracker entry is access-restricted. No researcher or organization has been publicly named for this finding.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (5.5/10)

Why this verdict

Chromium's own team rated this Medium, not High. Google's security team — who has full access to the bug details, exploit feasibility, and PartitionAlloc mitigation data — deliberately classified this below the NVD's 8.8. Their judgment carries significant weight.
Chromoting is opt-in with low enterprise penetration. Chrome Remote Desktop must be actively installed, configured, and *in use* during the attack. In enterprises managing 10K+ hosts, CRD adoption is marginal — dedicated VDI/RDP solutions dominate. This eliminates the vast majority of Chrome installations from the attack surface.
Network positioning requirement is non-trivial. The attacker must inject crafted STUN/TURN packets into an active session's signaling path. CRD sessions traverse Google's relay infrastructure over TLS. Blind injection from the internet is not feasible without a privileged network position or relay compromise.
No PoC, no ITW exploitation, bottom-quartile EPSS. At 0.29% EPSS (21st percentile), no public exploit code, and no observed exploitation, this is firmly in the theoretical-risk category. The SSVC assessment confirms: *not automatable*.
Chrome auto-updates eliminate the exposure window. For managed Chrome deployments (which represent the overwhelming majority of enterprise installs), auto-update pushes patches within 24-72 hours of stable release. The June 4 patch has been available for nearly 4 months.
Role multiplier: Chrome is an end-user browser, not a high-value-role component. Even in the worst case — a Chrome Remote Desktop session on an admin's workstation — the blast radius is user-level RCE on a single host, not domain/fleet/supply-chain compromise. CRD is not a hypervisor, IdP, PAM, CI/CD, backup system, or network edge appliance. No high-value-role floor applies.

Why not higher?

There is no evidence this vulnerability has been or can be reliably exploited in the wild. No public PoC exists, PartitionAlloc's MiraclePtr mitigations significantly harden Chrome against UAF exploitation, the Chromoting attack surface is only reachable when CRD is actively in use (an opt-in feature with low enterprise adoption), and the network positioning requirement for STUN/TURN packet injection is substantially harder than the CVSS AC:L suggests. Upgrading to HIGH would require either a public PoC, active exploitation, or a much broader attack surface.

Why not lower?

The underlying primitive — use-after-free leading to potential RCE — is a serious vulnerability class. If a PoC were developed and the PartitionAlloc mitigations bypassed, the impact on affected hosts would be genuine code execution at user privilege level. The SSVC rates the *technical impact* as total, which is correct. Dropping to LOW would understate the latent risk if exploitation techniques improve or if a motivated attacker targets CRD-heavy environments.

06 · Verification

Crowdsourced verification payload.

Run this on each target host (Linux/macOS) or adapt for Windows. Requires no special privileges — it reads the Chrome binary version. Example: bash check_cve_2026_11116.sh or chmod +x check_cve_2026_11116.sh && ./check_cve_2026_11116.sh

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check_cve_2026_11116.sh
# Checks if installed Google Chrome is vulnerable to CVE-2026-11116
# (Use-after-free in Chromoting, fixed in 149.0.7827.53)
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

FIXED_VERSION="149.0.7827.53"

get_chrome_version() {
  local chrome_bin=""
  # Try common Chrome binary locations
  for candidate in \
    google-chrome \
    google-chrome-stable \
    chromium-browser \
    chromium \
    "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"; do
    if command -v "$candidate" &>/dev/null || [ -x "$candidate" ]; then
      chrome_bin="$candidate"
      break
    fi
  done

  if [ -z "$chrome_bin" ]; then
    echo ""
    return
  fi

  "$chrome_bin" --version 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' | head -1
}

version_gte() {
  # Returns 0 if $1 >= $2 using sort -V
  [ "$(printf '%s\n%s' "$1" "$2" | sort -V | head -1)" = "$2" ]
}

VERSION=$(get_chrome_version)

if [ -z "$VERSION" ]; then
  echo "UNKNOWN — Google Chrome not found on this host."
  exit 2
fi

echo "Installed Chrome version: $VERSION"
echo "Fixed version:            $FIXED_VERSION"
echo "CVE: CVE-2026-11116 (Use-after-free in Chromoting)"
echo "---"

if version_gte "$VERSION" "$FIXED_VERSION"; then
  echo "PATCHED — Chrome $VERSION >= $FIXED_VERSION"
  exit 0
else
  echo "VULNERABLE — Chrome $VERSION < $FIXED_VERSION"
  exit 1
fi