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

Insufficient validation of untrusted input in Chromoting in Google Chrome prior to 149

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

This is the deadbolt behind the front door, not the open window

CVE-2026-11146 is an input-validation flaw in Chrome's Chromoting component affecting Google Chrome versions before 149.0.7827.53. The bug can let an attacker who has already compromised the renderer process use a crafted HTML page to potentially escape Chrome's sandbox, turning renderer-level code execution into a host-level foothold.

The published 9.6/CRITICAL score overstates the real enterprise urgency when assessed as a patch queue item. The decisive friction is that this is not initial access and not standalone RCE; it is a second-stage post-renderer compromise bug, and Google itself labeled the Chromium-side bug Medium. That keeps it important, because Chrome is everywhere and sandbox escapes are premium chain components, but it does not deserve top-of-queue treatment absent active exploitation.

"This is a valuable sandbox-escape link in a browser exploit chain, not a standalone internet-to-endpoint smash."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on a malicious page

The attacker needs a user to browse to attacker-controlled content, typically through phishing, malvertising, or a compromised site. The page itself is only delivery; this CVE does not give the attacker first-stage code execution on its own.
Conditions required:
  • User visits attacker-controlled or attacker-influenced HTML content
  • Chrome version is older than 149.0.7827.53
Where this breaks in practice:
  • Requires user interaction (UI:R)
  • Safe Browsing, email filtering, and content controls can block the lure before the browser is involved
Detection/coverage: Proxy, DNS, SWG, and email telemetry often catch the delivery stage; vulnerability scanners do not validate this step.
STEP 02

Exploit a separate renderer bug first

The attacker must already have renderer compromise from another browser bug or exploit chain. In practical terms, this means burning a separate V8/Blink/WebRTC-style client-side exploit before CVE-2026-11146 is even reachable as a meaningful privilege boundary crossing.
Conditions required:
  • A separate renderer-compromise vulnerability is available and works on the target build
  • The victim browses with a compatible exploit environment
Where this breaks in practice:
  • This is the biggest severity reducer: the attacker must already be partway through a successful browser exploit chain
  • Modern browser hardening, renderer isolation, exploit mitigations, and crash telemetry increase failure rates
Detection/coverage: EDR/browser telemetry may show renderer crashes, child-process anomalies, or exploit-prevention hits; commodity vuln scanners cannot assess this prerequisite.
STEP 03

Trigger the Chromoting validation flaw

With code already executing inside the renderer, the attacker abuses insufficient validation in Chromoting using crafted HTML to attempt a sandbox escape. This is the weaponized step where the bug matters: it is a sandbox-boundary bypass, not first-stage code execution.
Conditions required:
  • Renderer process already under attacker control
  • Affected Chromoting code path is reachable on the target build
Where this breaks in practice:
  • Bug details remain restricted in the Chromium issue, slowing broad weaponization
  • Successful sandbox escapes are usually brittle, version-sensitive, and harder to operationalize than the CVSS suggests
Detection/coverage: Little scanner coverage beyond version checks. High-value signals are browser exploit-protection alerts, unusual child-process launches, and sandbox violation telemetry.
STEP 04

Break out to user-context code execution

If the sandbox escape succeeds, the attacker can move from compromised renderer to code execution with the user's privileges on the endpoint. That turns a browser exploit into a real workstation compromise and enables credential theft, persistence attempts, or follow-on malware staging.
Conditions required:
  • Sandbox escape succeeds
  • Endpoint controls fail to block post-escape behavior
Where this breaks in practice:
  • EDR, application control, user-context restrictions, and post-exploitation telemetry can still stop or expose the operator
  • Blast radius is limited to the browsing user's endpoint, not a server-side mass compromise
Detection/coverage: EDR should have the best chance here: suspicious browser child processes, script interpreters, LOLBins, memory injections, or persistence writes.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo known active exploitation in reviewed sources. The bug is not in CISA KEV, and OpenCVE surfaces CISA SSVC as Exploitation: none.
Proof-of-concept availabilityNo public PoC surfaced in targeted web/GitHub searches at review time. Chromium issue 501709220 is still access-restricted, which usually slows copycat weaponization.
EPSS0.00047 from public aggregators sourcing FIRST; that is *very low*. Reviewed sources did not surface a current percentile, so do not over-interpret CVSS here.
KEV statusNot KEV-listed as of 2026-06-06 review. No CISA due date exists because it is absent from the catalog.
CVSS vector reality checkCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H models browser compromise impact well, but it misses the practical prerequisite in the description: the attacker must have already compromised the renderer process.
Affected versionsGoogle Chrome prior to 149.0.7827.53. Chrome release notes state desktop stable moved to 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/Mac).
Fixed version149.0.7827.53 or later. For managed estates, also watch channel pinning and lagging rollout rings; Chrome's staged release means some fleets trail for days.
Vendor vs realityMismatch: CISA ADP/NVD shows 9.6 Critical, but the Chrome CNA description explicitly says Chromium security severity: Medium. For defenders, the second-stage prerequisite is the deciding factor, and Google's label is closer to operational reality.
Exposure populationChrome is massively deployed; StatCounter showed roughly 73.26% worldwide desktop browser share for February 2026. *Inference:* internet-wide scanners like Shodan/Censys are the wrong lens because this is a client browser, not an internet-listening service.
Researcher / disclosure trailReported by Google on 2026-04-11 in the stable release notes list; CVE published 2026-06-04. Bug tracker reference is Chromium issue 501709220.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.6/10)

The single biggest factor is that this bug requires prior renderer compromise, which means the attacker already owns another exploit stage before CVE-2026-11146 matters. That sharply narrows the reachable population and pushes this out of emergency patch territory even though the end-state impact of a successful chain is serious.

HIGH Assessment that this is **not** a standalone internet-to-endpoint compromise
MEDIUM Assessment that enterprise patch priority should be **MEDIUM**, not HIGH

Why this verdict

  • Major downgrade: requires a prior renderer compromise — attacker position is effectively *post-exploitation inside the browser*, not unauthenticated remote code execution from scratch.
  • Further downgrade: user interaction is still required — the victim must browse to crafted content, so SWG, Safe Browsing, email controls, and user behavior all reduce reach.
  • Another downgrade: no exploitation evidence — no KEV listing, no public PoC found, and SSVC enrichment says Exploitation: none / Automatable: no.
  • Counterweight upward: Chrome is everywhere — the affected software population is huge, so a viable sandbox escape still matters when paired with another browser bug.
  • Counterweight upward: blast radius at the endpoint is real — if chained successfully, this converts renderer code exec into user-context compromise on a workstation.

Why not higher?

Because this CVE does not get the attacker into the box by itself. Requiring internal browser foothold plus a separate exploit stage is compounding friction, and there is no public evidence yet that operators are spending chains on this bug in the wild.

Why not lower?

Because sandbox escapes in Chrome are not hygiene-only bugs. In a product with Chrome's deployment footprint, a reliable chain component can materially raise attacker success once the first-stage renderer bug exists, so this should stay above backlog-only treatment.

05 · Compensating Control

What to do — in priority order.

  1. Unpin lagging Chrome channels — Find OUs, VDI pools, kiosk builds, and gold images pinned below 149.0.7827.53 and remove version pinning that blocks normal browser security uptake. For a MEDIUM noisgate verdict there is no mitigation SLA — go straight to the 365-day remediation window, but do this early because browser version drift is what turns chain bugs into long-tail exposure.
  2. Verify auto-update actually lands — Do not assume Chrome updated just because policy says it should. Validate managed endpoints are receiving the stable build and restarting into it; for this MEDIUM verdict there is no mitigation SLA, so use the 365-day remediation window to clean up update reliability rather than treating this like a fire drill.
  3. Harden web delivery controls — Keep Safe Browsing, SWG, email URL defense, and malvertising filtering tuned because they cut off the crafted-page delivery stage before any browser chain executes. There is no mitigation SLA for MEDIUM here, but these controls reduce chain completion while remediation proceeds inside the 365-day window.
  4. Watch browser child-process and exploit telemetry — Prioritize detections for suspicious browser-launched shells, script engines, LOLBins, and memory abuse from chrome.exe or Chrome child processes. This does not patch the bug, but it is the most useful runtime control if an attacker tries to turn a renderer exploit into post-sandbox endpoint actions.
What doesn't work
  • A WAF does not help; this is a client-side browser issue, not a server-side web app flaw you can shield at the perimeter.
  • Simple port scanning does not measure exposure; Chrome is not an internet-listening service, so Shodan-style counts tell you almost nothing about your affected population.
  • Treating this as a standalone RCE leads to bad prioritization; the real risk comes only when another renderer exploit is already in play.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your endpoint audit tooling. Invoke it with python3 check_cve_2026_11146.py on macOS/Linux or py check_cve_2026_11146.py on Windows; standard user rights are usually enough because it reads local install metadata and common binary paths.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_cve_2026_11146.py
# Detect whether locally installed Google Chrome is vulnerable to CVE-2026-11146
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys
from shutil import which

FIXED_VERSION = (149, 0, 7827, 53)


def parse_version(text):
    if not text:
        return None
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def compare_versions(a, b):
    if a is None or b is None:
        return None
    return (a > b) - (a < b)


def run_cmd(cmd):
    try:
        cp = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
        out = (cp.stdout or '') + '\n' + (cp.stderr or '')
        return out.strip()
    except Exception:
        return ''


def windows_version():
    candidates = [
        r'C:\Program Files\Google\Chrome\Application\chrome.exe',
        r'C:\Program Files (x86)\Google\Chrome\Application\chrome.exe',
        os.path.expandvars(r'%LOCALAPPDATA%\Google\Chrome\Application\chrome.exe'),
    ]

    for path in candidates:
        if path and os.path.exists(path):
            out = run_cmd(['powershell', '-NoProfile', '-Command', f"(Get-Item '{path}').VersionInfo.ProductVersion"])
            ver = parse_version(out)
            if ver:
                return ver, path

    reg_queries = [
        [
            'reg', 'query',
            r'HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe',
            '/ve'
        ],
        [
            'reg', 'query',
            r'HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe',
            '/ve'
        ],
    ]

    for q in reg_queries:
        out = run_cmd(q)
        m = re.search(r'REG_SZ\s+(.+chrome\.exe)', out, re.IGNORECASE)
        if m:
            path = m.group(1).strip()
            if os.path.exists(path):
                pout = run_cmd(['powershell', '-NoProfile', '-Command', f"(Get-Item '{path}').VersionInfo.ProductVersion"])
                ver = parse_version(pout)
                if ver:
                    return ver, path

    return None, None


def mac_version():
    app = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
    if os.path.exists(app):
        out = run_cmd([app, '--version'])
        ver = parse_version(out)
        if ver:
            return ver, app
    return None, None


def linux_version():
    binaries = [
        'google-chrome',
        'google-chrome-stable',
        '/opt/google/chrome/google-chrome',
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable',
    ]
    for b in binaries:
        path = b if os.path.isabs(b) else which(b)
        if path:
            out = run_cmd([path, '--version'])
            ver = parse_version(out)
            if ver:
                return ver, path
    return None, None


def main():
    system = platform.system().lower()
    ver = None
    path = None

    if 'windows' in system:
        ver, path = windows_version()
    elif 'darwin' in system:
        ver, path = mac_version()
    elif 'linux' in system:
        ver, path = linux_version()
    else:
        print('UNKNOWN: unsupported platform for this checker')
        sys.exit(2)

    if ver is None:
        print('UNKNOWN: Google Chrome not found or version unreadable')
        sys.exit(2)

    cmp_result = compare_versions(ver, FIXED_VERSION)
    ver_str = '.'.join(str(x) for x in ver)
    fixed_str = '.'.join(str(x) for x in FIXED_VERSION)

    if cmp_result < 0:
        print(f'VULNERABLE: Google Chrome {ver_str} detected at {path}; fixed version is {fixed_str}')
        sys.exit(1)
    else:
        print(f'PATCHED: Google Chrome {ver_str} detected at {path}; fixed threshold is {fixed_str}')
        sys.exit(0)


if __name__ == '__main__':
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: treat this as a chain component review, not a panic patch. Query your fleet for Chrome versions, clear any pinning that leaves endpoints below 149.0.7827.53, and verify normal browser auto-update is actually working; for a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window. Use the noisgate remediation SLA to get the estate fully onto the fixed build within 365 days, but operationally you should clean up lagging rings much sooner because the risk here is long-tail browser drift feeding future exploit chains.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop
  2. NVD - CVE-2026-11146
  3. OpenCVE - CVE-2026-11146
  4. Tenable - CVE-2026-11146
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS API documentation
  7. Chromium Security Severity Guidelines
  8. StatCounter Desktop Browser Market Share Worldwide
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.