This is a sharp blade hidden inside a tool most enterprises barely hand out
CVE-2026-11116 is a CWE-416 use-after-free in Chrome's Chromoting stack, the code behind Chrome Remote Desktop. Affected builds are Chrome versions before 149.0.7827.53; Google’s rollout shows 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and Mac as the fixed train. The bug is triggered by malicious network traffic, so this is not about a random website tab by itself; it is about traffic reaching the remote-desktop feature path.
The supplied HIGH 8.8 baseline overstates enterprise urgency for most fleets. The deciding friction is not exploit physics but reachability: most Chrome installs are just browsers, while Chromoting/Chrome Remote Desktop is a governed feature that many enterprises disable, restrict to LAN/VPN, or simply do not use at scale. No KEV listing, very low EPSS, no public exploit tooling, and non-scannable client-side exposure all push this down to MEDIUM for patch-priority purposes.
4 steps from start to impact.
Find a host where Chromoting is actually in play
- Chrome version earlier than
149.0.7827.53 - Chromoting / Chrome Remote Desktop present and operational enough to exercise the code path
- Network policy allows the required outbound/peer connectivity
- Chrome Remote Desktop is often disabled by policy in managed fleets
- The feature is far less prevalent than Chrome itself
- This is not an internet-listenable server you can mass-scan with Shodan/Censys
Deliver malicious network traffic into the Chromoting path
- Attacker can act as the remote party or otherwise influence traffic reaching the Chromoting handler
- Session setup or feature invocation path is available
- Session establishment and feature use are not universal
- Google documents admin controls for firewall traversal and use restrictions
- User/org workflow has to expose the remote-desktop function in the first place
Trigger the use-after-free and land code execution
AV:N/AC:H/UI:N and AV:N/AC:L/UI:R, which is a tell that even upstream scorers are not settled on the practical exploit chain.- Precise traffic sequence reaches the buggy object lifetime edge case
- Target build matches the vulnerable range
- Use-after-free exploitation is usually crash-prone before it is reliable
- Modern platform mitigations raise exploit-development cost
- No public exploit or in-the-wild evidence reduces immediate confidence in reliability
chromoting crashes, child-process anomalies, or memory-protection telemetry, but commodity vuln scanners will not validate exploitability.Convert code exec into meaningful host impact
- Successful initial code execution
- Target user context provides something worth taking
- User-context execution may not equal full host takeover
- EDR, app control, and browser hardening can still catch follow-on activity
The supporting signals.
| In-the-wild status | No public exploitation evidence found in the sources reviewed, and not listed in CISA KEV. |
|---|---|
| Proof-of-concept availability | No public PoC or exploit repo found for CVE-2026-11116; current evidence points to private/custom exploit development only. |
| EPSS | 0.00038 (user-supplied intel) — extremely low short-term exploitation probability. |
| KEV status | No — not present in the CISA KEV catalog. |
| CVSS and interpretation | Supplied baseline is 8.8 / CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, but adjacent Chromoting records in NVD show scoring churn including AV:N/AC:H/UI:N and vendor language from Low to Critical by platform. That inconsistency is a warning not to trust the raw number blindly. |
| Affected versions | Chrome before 149.0.7827.53. The vulnerable functionality is in Chromoting / Chrome Remote Desktop rather than generic browsing alone. |
| Fixed versions | Google’s release train shows 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and Mac in the early stable rollout. |
| Exposure reality | Not meaningfully internet-scannable with Shodan/Censys/FOFA because this is a client/browser feature path, not a broadly exposed listener. Real exposure is the subset of managed endpoints where Chrome Remote Desktop is enabled and used. |
| Enterprise controls | Google documents policy controls to disable Chrome Remote Desktop, and a network policy to disable firewall traversal so access is limited to LAN/VPN users only. |
| Disclosure / reporting | Published 2026-06-04 by the Chrome CNA. No public individual researcher attribution was exposed in the reviewed sources. |
noisgate verdict.
The single biggest downward driver is feature-gated reachability: this is a Chromoting/Chrome Remote Desktop flaw, not a ubiquitous drive-by web bug hitting every browser session. You should care if your fleet uses Chrome Remote Desktop, but for the average 10,000-endpoint enterprise the exposed population is narrow enough that an 8.8 patch panic is not justified.
Why this verdict
- Down from 8.8 because reachability is gated — the attacker needs the Chromoting / Chrome Remote Desktop path, which implies a much smaller exposed population than 'Chrome installed'.
- Down because it is not mass-scannable internet edge tech — this is a client-side/browser feature, so broad opportunistic exploitation at internet scale is harder to operationalize.
- Down because the signals are cold — no KEV, tiny EPSS, and no public PoC mean there is no evidence defenders should treat this as a live-fire campaign item.
- Still not LOW because impact can be serious where deployed — if you do run Chrome Remote Desktop on vulnerable endpoints, the stated outcome is arbitrary code execution, which is not backlog fluff.
Why not higher?
I am not taking this to HIGH because too many prerequisites narrow the real-world population: a vulnerable Chrome build is not enough by itself; the Chromoting feature must be exposed in practice. That prerequisite implies a subset of endpoints with a specific remote-access workflow, and modern fleet policy can disable or constrain that workflow altogether.
Why not lower?
I am not dropping this to LOW because the technical outcome is still code execution, not a cosmetic or info-leak bug. For the organizations that do rely on Chrome Remote Desktop, this is a legitimate attack surface with meaningful blast radius on the affected hosts.
What to do — in priority order.
- Disable Chrome Remote Desktop where it is not required — Use Google admin policy to turn off Chrome Remote Desktop for users and managed browsers. For a MEDIUM verdict there is no mitigation SLA, but this is still the fastest exposure reduction for the small subset of hosts that actually need attention while you work toward remediation within 365 days.
- Restrict firewall traversal — Set the Chrome Remote Desktop policy so access is limited to LAN/VPN users only where business use allows it. That does not fix the bug, but it materially shrinks who can reach the vulnerable path; for MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window and use this selectively on higher-risk remote-support hosts.
- Prioritize remote-support and admin endpoints first — Do not waste cycles treating every Chrome install as equal. Target systems used for remote administration, help desk, shared support, and always-on unattended remote access, because those are the places where Chromoting exposure is most plausible; complete patching within the 365-day remediation window.
- Watch for chromoting crash and child-process telemetry — Tune EDR to surface anomalous
chromotingor Chrome process crashes, unusual child processes, and post-exploitation behaviors around remote-support endpoints. This is detective control only, but it is more useful than perimeter scanning for a client-side feature bug.
- A WAF does not help; this is not a web-app parsing bug at your edge.
- Generic internet attack-surface scanners will not tell you who is actually exposed, because vulnerable Chrome clients are not the same thing as internet-listenable services.
- Relying on email filtering is weak fit here; the described trigger is malicious network traffic in Chromoting, not a phishing attachment chain.
Crowdsourced verification payload.
Run this on the target endpoint or via your EDR/script runner. Invoke it with python3 check_chrome_11116.py (Windows: py check_chrome_11116.py). It needs no admin rights and checks installed Chrome/Chromium version against the fixed floor 149.0.7827.53, then prints VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env python3
# check_chrome_11116.py
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
from pathlib import Path
FIXED = (149, 0, 7827, 53)
def parse_ver(text):
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
if not m:
return None
return tuple(int(x) for x in m.groups())
def ver_to_str(v):
return '.'.join(str(x) for x in v)
def cmp_ver(a, b):
return (a > b) - (a < b)
def run_cmd(cmd):
try:
p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
out = (p.stdout or '') + '\n' + (p.stderr or '')
return p.returncode, out.strip()
except Exception:
return None, ''
def get_windows_version():
candidates = [
Path(os.environ.get('ProgramFiles', 'C:/Program Files')) / 'Google/Chrome/Application/chrome.exe',
Path(os.environ.get('ProgramFiles(x86)', 'C:/Program Files (x86)')) / 'Google/Chrome/Application/chrome.exe',
Path(os.environ.get('LocalAppData', '')) / 'Google/Chrome/Application/chrome.exe',
Path(os.environ.get('ProgramFiles', 'C:/Program Files')) / 'Chromium/Application/chrome.exe',
Path(os.environ.get('ProgramFiles(x86)', 'C:/Program Files (x86)')) / 'Chromium/Application/chrome.exe',
]
for exe in candidates:
if exe and exe.exists():
ps = [
'powershell', '-NoProfile', '-Command',
f"(Get-Item '{str(exe)}').VersionInfo.ProductVersion"
]
rc, out = run_cmd(ps)
v = parse_ver(out)
if v:
return str(exe), v
return None, None
def get_macos_version():
candidates = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
'/Applications/Chromium.app/Contents/MacOS/Chromium',
]
for exe in candidates:
if os.path.exists(exe):
rc, out = run_cmd([exe, '--version'])
v = parse_ver(out)
if v:
return exe, v
return None, None
def get_linux_version():
bins = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']
for b in bins:
exe = shutil.which(b)
if exe:
rc, out = run_cmd([exe, '--version'])
v = parse_ver(out)
if v:
return exe, v
return None, None
def main():
system = platform.system().lower()
path = None
version = None
if 'windows' in system:
path, version = get_windows_version()
elif 'darwin' in system:
path, version = get_macos_version()
elif 'linux' in system:
path, version = get_linux_version()
if not version:
print('UNKNOWN - Chrome/Chromium not found or version unreadable')
sys.exit(2)
print(f'Detected: {path} -> {ver_to_str(version)}')
print(f'Fixed floor: {ver_to_str(FIXED)}')
if cmp_ver(version, FIXED) < 0:
print('VULNERABLE')
sys.exit(1)
else:
print('PATCHED')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
.54 is acceptable per Google’s early stable rollout), and disable the feature where it is unnecessary. For this MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window; the noisgate remediation SLA is to get affected systems patched within 365 days, with the exposed remote-support subset handled first in your normal browser-update rings.Sources
- Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
- Vulnerability Lookup entry for CVE-2026-11116
- Google Admin Help - Control use of Chrome Remote Desktop
- Google Admin Help - Network guide for Chrome Remote Desktop
- CISA Known Exploited Vulnerabilities Catalog
- NVD adjacent Chromoting record - CVE-2026-11224 (Linux)
- NVD adjacent Chromoting record - CVE-2026-10893
- Google Chrome Help - Access another computer with Chrome Remote Desktop
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.