CVE-2026-11118 · Chrome WebRTC Use-After-Free Renderer RCE

01 · The Real Story

Like finding a loaded gun locked in a glass case — dangerous in theory, but you need a second break-in to actually reach it

CVE-2026-11118 is a use-after-free (CWE-416) in Chrome's WebRTC implementation affecting all versions prior to 149.0.7827.53. The flaw sits in the asynchronous media pipeline that manages peer connections and data channels: a dangling pointer to freed memory persists after an object lifecycle transition, and a crafted HTML page can trigger controlled reuse of that memory to hijack execution flow. The impact is code execution inside Chrome's renderer sandbox — the attacker gains a foothold in the browser process, but cannot touch the operating system, filesystem, or network stack without chaining a separate sandbox-escape vulnerability.

The vendor CVSS of 8.8 HIGH overstates the real-world risk substantially. Chromium's own security team rated this bug Medium on their internal severity scale, which explicitly accounts for the sandbox boundary that CVSS 3.1 ignores. A renderer-process compromise without sandbox escape gives the attacker access to in-browser data (cookies, session tokens, DOM content of open tabs) but not persistent OS-level access, lateral movement capability, or credential theft beyond the browser context. With no public proof-of-concept, no known exploitation in the wild, an EPSS of 0.39% (32nd percentile), and Chrome's aggressive auto-update cycle that patches most of the install base within days, the realistic severity for enterprise fleet management lands squarely at MEDIUM.

"Sandboxed renderer RCE with no escape, no PoC, no wild exploitation — routine browser hygiene."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver the malicious page

The attacker hosts or injects a crafted HTML page containing JavaScript that initiates WebRTC peer connections with specific lifecycle sequences. Delivery can occur via phishing link, malvertising, watering-hole compromise, or iframe injection on a compromised site. No specific weaponized tool is known for this CVE — delivery would use standard social-engineering and web-exploitation frameworks (Cobalt Strike, Gophish, BeEF).

Conditions required:

Victim must click a link or navigate to attacker-controlled content
Attacker must have hosting infrastructure or ability to inject into a legitimate site

Where this breaks in practice:

Enterprise email gateways (Proofpoint, Mimecast, Microsoft Defender for Office 365) block known malicious URLs
Chrome Safe Browsing flags flagged domains before page load
Web proxies and SWGs (Zscaler, Netskope) block uncategorized or newly-registered domains

Detection/coverage: URL reputation services (Zscaler, Palo Alto URL Filtering, CrowdStrike Falcon) flag known delivery infrastructure. Email gateway click-time URL rewriting provides post-delivery visibility.

STEP 02

Trigger the UAF in WebRTC

The page's JavaScript creates and tears down RTCPeerConnection objects or data channels in a specific sequence that frees an internal object while a dangling pointer persists. The attacker must trigger a deterministic lifecycle bug or win a race condition in the WebRTC media pipeline to produce the use-after-free condition. No public PoC exists, so the exact trigger sequence is unknown outside Google and the reporting researcher.

Conditions required:

Victim's Chrome version must be < 149.0.7827.53
WebRTC must not be disabled via enterprise policy (WebRtcAllowedUrls)

Where this breaks in practice:

Chrome auto-updates patch 95%+ of consumer installs within 7 days of a stable release
Enterprise-managed Chrome via GPO/MDM typically follows within 14–30 days
Chrome's MiraclePtr (raw_ptr<T>) actively detects dangling pointers in many code paths, causing a crash instead of exploitation

Detection/coverage: No known IDS/IPS signatures or YARA rules specific to this CVE. Generic heap-spray detection may trigger in endpoint agents. Chrome crash reports with specific WebRTC stack traces may indicate exploitation attempts.

STEP 03

Achieve renderer-process code execution

Successful heap manipulation after the free allows the attacker to overwrite the freed object with controlled data, hijacking a virtual function table pointer or similar control-flow target. The attacker achieves arbitrary code execution within the Chrome renderer process sandbox — gaining access to in-browser data (cookies, session tokens, DOM content, autofill data) but constrained by Chrome's sandbox policy from accessing the OS.

Conditions required:

Attacker must defeat ASLR, Control Flow Integrity (CFI), and PartitionAlloc mitigations
The specific heap layout must be controllable enough for reliable exploitation

Where this breaks in practice:

Chrome's multi-layered heap hardening (PartitionAlloc, MiraclePtr, CFI, stack canaries) makes reliable exploitation significantly harder than the CVSS implies
No public PoC after 118 days suggests weaponization is non-trivial
V8 sandbox and site-isolation further limit cross-origin data access

Detection/coverage: EDR agents (CrowdStrike, SentinelOne, Defender for Endpoint) monitoring renderer process behavior — unusual child process spawning, memory allocation patterns — can flag anomalies. Chrome's built-in crash reporting captures exploitation-indicative stack traces.

STEP 04

Escape the sandbox (REQUIRED for OS-level impact)

The renderer sandbox restricts filesystem access, network calls, and IPC to a narrow set of allowed Mojo operations. To achieve the C:H/I:H/A:H impact the CVSS vector claims, the attacker needs a separate sandbox-escape vulnerability — a kernel bug, a GPU process exploit (e.g., CVE-2026-11697 which was patched separately), or a Mojo IPC flaw — chained with this renderer RCE. Without this step, the attack terminates at sandboxed data theft.

Conditions required:

A second, unchained vulnerability must exist and be exploitable from the sandboxed renderer
The sandbox escape must be compatible with the Chrome version and OS in use

Where this breaks in practice:

Sandbox escapes are rare, expensive ($250K+ in Chrome VRP), and typically reserved for state-level actors
No sandbox escape is known to be chained with CVE-2026-11118
Chrome's multi-process architecture means each site runs in its own sandboxed process, limiting lateral reach even within the browser

Detection/coverage: EDR monitors for sandbox escape indicators: unexpected child processes from chrome.exe/chromium, direct syscalls from renderer threads, privilege escalation attempts, and anomalous IPC patterns.

03 · Compensating Control

MEDIUM 5.5→IGNORE 0.0

SEVERITY REDUCED

Update Chrome to >= 149.0.7827.53 fleet-wide — This is the definitive fix. Push via GPO (GoogleUpdate ADMX), MDM (Intune, JAMF, Workspace ONE), or Chrome Browser Cloud Management. At MEDIUM severity under the noisgate remediation SLA, deploy within 365 days — but given the simplicity of browser auto-update, confirm fleet-wide patching within 30 days.

MEDIUM 5.5→IGNORE 0.0

SEVERITY REDUCED

Disable WebRTC via enterprise policy if operationally feasible — Set WebRtcAllowedUrls to an empty list or restrict WebRtcUdpPortRange via Chrome enterprise policy. This eliminates the attack surface entirely but breaks web-based video conferencing (Google Meet, Zoom web, Teams web). Only viable for kiosk, terminal, or limited-use browser deployments. No mitigation SLA applies at MEDIUM — implement if your deployment profile allows.

MEDIUM 5.5→IGNORE 0.0

SEVERITY REDUCED

Enforce Chrome version floor at >= 149 via GPO/MDM — Set TargetVersionPrefix to 149. or higher to prevent rollback below the patched version. This ensures even if auto-update fails or is delayed, the minimum version floor stays above the vulnerable range. No mitigation SLA at MEDIUM — go straight to the 365-day remediation window.

MEDIUM 5.5→LOW 2.0

SEVERITY REDUCED

Deploy browser isolation (Menlo, Zscaler, Cloudflare RBI) — Remote browser isolation renders web content in a cloud container. Even if the UAF triggers, code execution occurs in the isolation environment, not on the endpoint. Breaks the attack path at Step 3 by moving the renderer off the endpoint entirely. Residual risk is limited to data exposure within the isolated session.

MEDIUM 5.5→MEDIUM 4.5

Harden URL filtering and email gateway rules — Block uncategorized URLs, newly-registered domains (< 30 days), and enforce click-time URL rewriting (Proofpoint, Mimecast, Microsoft Defender for Office 365). Raises delivery friction at Step 1 but does not eliminate the vulnerability. No mitigation SLA at MEDIUM — implement as part of standard hygiene.

What doesn't work

Network segmentation / firewall rules — This is a client-side browser bug triggered by visiting a web page. Server-to-server network controls have no effect on the attack path.
EDR alone — EDR monitors post-exploitation OS-level behavior, but the exploit executes inside Chrome's sandbox. A sandboxed renderer compromise produces no OS-level indicators unless the attacker also escapes the sandbox.
WAF (Web Application Firewall) — WAFs protect server-side applications. This vulnerability is in the browser client, not in a web server you host.
Disabling JavaScript — While this would prevent the WebRTC trigger, it breaks virtually all modern web applications and is not a viable enterprise control.

04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitation	No known exploitation. Not listed in CISA KEV. No campaigns documented by Mandiant, CrowdStrike, Google TAG, or any threat intelligence vendor as of 2026-09-30.
Proof-of-concept	No public PoC found. pocindex.io returns no results for this CVE. No GitHub repositories named CVE-2026-11118. No Nuclei templates, ExploitDB entries, or Metasploit modules identified. The Chromium bug #501424047 remains access-restricted, suggesting details are still embargoed.
EPSS	0.00387 (0.39%) — 32nd percentile. Well below the ~6% threshold where exploitation becomes statistically likely within 30 days. Indicates very low predicted exploitation probability.
CISA KEV	Not listed 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. The vector assumes full C/I/A impact, which is misleading — the advisory explicitly states execution occurs "inside a sandbox." CVSS 3.1 has no modifier for sandbox containment, inflating the score.
Chromium severity	Medium. Chromium's internal severity rating explicitly accounts for sandbox containment — a renderer RCE without escape is Medium in their framework, not High. This is the vendor's own risk assessment.
Affected versions	Google Chrome < 149.0.7827.53 on all platforms (Windows, macOS, Linux, ChromeOS). Also affects Chromium-based browsers (Microsoft Edge, Brave, Opera, Vivaldi) on builds derived from Chromium < 149.
Fixed versions	Chrome 149.0.7827.53 (Linux), 149.0.7827.53/54 (Windows/Mac). Debian: DSA-6325-1. Ubuntu: chromium-browser snap auto-updates. Edge: check Microsoft's Chromium update schedule.
Scanning / exposure	Not applicable — client-side browser vulnerability, not a network service. No Shodan/Censys/GreyNoise/FOFA exposure surface. Attack surface = endpoints running unpatched Chrome that visit attacker-controlled pages.
Disclosure	Published 2026-06-04 via Chrome stable channel update. Reported through Chromium bug bounty (issue #501424047). Researcher name withheld pending bug restriction lift.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (5.5/10)

Why this verdict

Sandbox containment (major downward pressure): The advisory explicitly states code execution occurs "inside a sandbox." The CVSS vector's C:H/I:H/A:H assumes full-scope impact, but real impact is limited to the renderer process. Without a chained sandbox escape, the attacker cannot access the OS, filesystem, registry, or network stack.
Chromium's own Medium rating confirms the sandbox adjustment. Google's security team, who built and maintain the sandbox, rated this Medium. They have better signal on exploitability and containment than an automated CVSS calculator.
No PoC, no weaponization after 118 days (downward pressure). Zero public exploit code since disclosure. No Nuclei templates, no ExploitDB, no Metasploit module. The restricted Chromium bug tracker suggests the trigger is non-trivial.
Chrome auto-update shrinks the vulnerable population rapidly (downward pressure). 95%+ of consumer installs patch within 7 days; enterprise-managed installs within 14–30 days via GPO/MDM. The remaining vulnerable population 118 days post-patch is negligible.
EPSS at 0.39% confirms low exploitation probability (downward pressure). 32nd percentile — less likely to be exploited than two-thirds of all scored CVEs.
Role multiplier: Chrome is a client-side application — workstations and laptops, categories (a) and (b). It is NOT a domain controller, identity provider, hypervisor, CI/CD system, backup appliance, network edge, or any canonically high-value-role component. The blast radius of a sandboxed renderer compromise is limited to in-browser session data for the duration of the browser session. Even with a hypothetical sandbox escape, the outcome is single-host endpoint compromise — not domain takeover, fleet compromise, or supply-chain pivot. No high-value-role floor override applies.

Why not higher?

The vulnerability is explicitly sandboxed — a renderer-process compromise without escape gives the attacker no persistent foothold, no credential store access beyond in-browser data, and no lateral movement capability. No exploitation chain has been demonstrated, no PoC exists, and Chrome is not a high-value-role component. Chromium's own security team rates it Medium. Elevating to HIGH would require evidence of a chained sandbox escape or active exploitation — neither exists.

Why not lower?

The vulnerability is still a remotely-triggerable RCE reachable with zero authentication and low attack complexity. WebRTC UAFs have historically been chained in advanced state-sponsored campaigns. A sandboxed foothold still exposes in-browser session data — OAuth tokens, cookies, autofilled credentials — which can enable account takeover. The bug class recurs frequently in WebRTC's complex async media pipeline, and future PoC development is plausible.

06 · Verification

Crowdsourced verification payload.

Run on each target host (the endpoint where Chrome is installed). No elevated privileges required. Works on Linux, macOS, and Windows (via Git Bash, WSL, or Cygwin). Invoke: bash check_cve_2026_11118.sh

noisgate-verify.sh

BASHREAD-ONLYSAFE

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

set -euo pipefail

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

get_chrome_version() {
  local ver=""
  # Linux
  if command -v google-chrome &>/dev/null; then
    ver=$(google-chrome --version 2>/dev/null | grep -oP '[\d]+\.[\d]+\.[\d]+\.[\d]+')
  elif command -v google-chrome-stable &>/dev/null; then
    ver=$(google-chrome-stable --version 2>/dev/null | grep -oP '[\d]+\.[\d]+\.[\d]+\.[\d]+')
  elif command -v chromium-browser &>/dev/null; then
    ver=$(chromium-browser --version 2>/dev/null | grep -oP '[\d]+\.[\d]+\.[\d]+\.[\d]+')
  elif command -v chromium &>/dev/null; then
    ver=$(chromium --version 2>/dev/null | grep -oP '[\d]+\.[\d]+\.[\d]+\.[\d]+')
  # macOS
  elif [ -d "/Applications/Google Chrome.app" ]; then
    ver=$(/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --version 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+')
  # Windows (Git Bash / WSL)
  elif [ -f "/mnt/c/Program Files/Google/Chrome/Application/chrome.exe" ]; then
    ver=$("/mnt/c/Program Files/Google/Chrome/Application/chrome.exe" --version 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+')
  fi
  echo "$ver"
}

compare_version() {
  local IFS='.'
  read -ra V <<< "$1"
  local maj=${V[0]:-0} min=${V[1]:-0} bld=${V[2]:-0} pat=${V[3]:-0}
  if (( maj > FIXED_MAJOR )); then return 0; fi
  if (( maj < FIXED_MAJOR )); then return 1; fi
  if (( min > FIXED_MINOR )); then return 0; fi
  if (( min < FIXED_MINOR )); then return 1; fi
  if (( bld > FIXED_BUILD )); then return 0; fi
  if (( bld < FIXED_BUILD )); then return 1; fi
  if (( pat >= FIXED_PATCH )); then return 0; fi
  return 1
}

VERSION=$(get_chrome_version)

if [ -z "$VERSION" ]; then
  echo "UNKNOWN - Could not detect Chrome/Chromium installation"
  exit 2
fi

echo "Detected Chrome version: $VERSION"
echo "Fixed version: ${FIXED_MAJOR}.${FIXED_MINOR}.${FIXED_BUILD}.${FIXED_PATCH}"

if compare_version "$VERSION"; then
  echo "PATCHED - Chrome $VERSION >= $FIXED_MAJOR.$FIXED_MINOR.$FIXED_BUILD.$FIXED_PATCH"
  exit 0
else
  echo "VULNERABLE - Chrome $VERSION < $FIXED_MAJOR.$FIXED_MINOR.$FIXED_BUILD.$FIXED_PATCH"
  echo "CVE-2026-11118: Use-after-free in WebRTC allows sandboxed code execution"
  exit 1
fi