← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11116 · CWE-416 · Disclosed 2026-06-04

Use after free in Chromoting in Google Chrome prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"Real bug, real RCE potential, but the reachable population is much smaller than the 8.8 suggests."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Find a host where Chromoting is actually in play

The attacker needs a target running vulnerable Chrome with the Chromoting / Chrome Remote Desktop feature reachable in practice. This is the real gate: the bug lives in a browser component, but the attack surface only matters when the remote-desktop path is enabled and used. Weaponized tooling here is a custom Chromoting protocol harness; I found no public exploit kit or turnkey PoC tied to this CVE.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Version scanners can flag vulnerable Chrome builds, but most scanners cannot tell whether the Chromoting path is actually enabled or used.
STEP 02

Deliver malicious network traffic into the Chromoting path

The attacker then has to feed crafted traffic into the vulnerable protocol handler. For a defender, this matters because the route is narrower than a generic web-content bug: this is remote-desktop traffic, not just any HTML. The likely weapon is a bespoke peer or relay-side traffic generator built to fuzz or shape Chromoting messages.
Conditions required:
  • Attacker can act as the remote party or otherwise influence traffic reaching the Chromoting handler
  • Session setup or feature invocation path is available
Where this breaks in practice:
  • 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
Detection/coverage: Network IDS coverage is weak unless you already inspect and baseline Chrome Remote Desktop use; most orgs do not have signature-grade detection for malformed Chromoting traffic.
STEP 03

Trigger the use-after-free and land code execution

If the crafted traffic reaches the vulnerable state machine, memory corruption can produce arbitrary code execution. The exact exploit reliability is unknown publicly, and similar Chromoting records show scoring churn between 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.
Conditions required:
  • Precise traffic sequence reaches the buggy object lifetime edge case
  • Target build matches the vulnerable range
Where this breaks in practice:
  • 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
Detection/coverage: EDR may see browser or chromoting crashes, child-process anomalies, or memory-protection telemetry, but commodity vuln scanners will not validate exploitability.
STEP 04

Convert code exec into meaningful host impact

Even after code execution, the attacker still has to turn that foothold into useful access on the endpoint. Depending on where execution lands, they may still need post-exploitation work for persistence, credential access, or privilege elevation. The weapon here becomes standard post-exploitation tooling rather than anything unique to Chromoting.
Conditions required:
  • Successful initial code execution
  • Target user context provides something worth taking
Where this breaks in practice:
  • User-context execution may not equal full host takeover
  • EDR, app control, and browser hardening can still catch follow-on activity
Detection/coverage: EDR is strongest here: anomalous child processes, LOLBin misuse, token abuse, and suspicious persistence all become visible once the exploit leaves the vulnerable process.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found in the sources reviewed, and not listed in CISA KEV.
Proof-of-concept availabilityNo public PoC or exploit repo found for CVE-2026-11116; current evidence points to private/custom exploit development only.
EPSS0.00038 (user-supplied intel) — extremely low short-term exploitation probability.
KEV statusNo — not present in the CISA KEV catalog.
CVSS and interpretationSupplied 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 versionsChrome before 149.0.7827.53. The vulnerable functionality is in Chromoting / Chrome Remote Desktop rather than generic browsing alone.
Fixed versionsGoogle’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 realityNot 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 controlsGoogle 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 / reportingPublished 2026-06-04 by the Chrome CNA. No public individual researcher attribution was exposed in the reviewed sources.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.9/10)

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.

HIGH Affected version range and fixed train
MEDIUM Practical enterprise exposure reduction from Chromoting being niche/controllable
LOW Exploit reliability details, because the underlying bug ticket is not public

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 coldno 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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. Watch for chromoting crash and child-process telemetry — Tune EDR to surface anomalous chromoting or 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/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()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: do not treat this like a universal Chrome fire drill. First, pull an inventory of endpoints where Chrome Remote Desktop / Chromoting is enabled or expected, verify those systems are on 149.0.7827.53+ (Windows/Mac .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

  1. Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
  2. Vulnerability Lookup entry for CVE-2026-11116
  3. Google Admin Help - Control use of Chrome Remote Desktop
  4. Google Admin Help - Network guide for Chrome Remote Desktop
  5. CISA Known Exploited Vulnerabilities Catalog
  6. NVD adjacent Chromoting record - CVE-2026-11224 (Linux)
  7. NVD adjacent Chromoting record - CVE-2026-10893
  8. Google Chrome Help - Access another computer with Chrome Remote Desktop
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.