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

Insufficient validation of untrusted input in Enterprise Reporting in Google Chrome prior to 149

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

This is a second lock behind a first broken door, not a front-door smash

CVE-2026-11120 is an improper input validation bug in Chrome's Enterprise Reporting component. Google says versions before 149.0.7827.53 are affected, with desktop fixes shipped in 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows and macOS. The important buried detail is the prerequisite: the attacker must already have compromised the renderer process and then use a crafted HTML page to try to turn that foothold into a sandbox escape.

The vendor-style 9.6 CRITICAL score overstates standalone enterprise risk because it prices the bug as if the attacker can go straight from web content to full compromise. In reality this is a stage-two browser exploit that usually needs a separate renderer RCE/UXSS bug, plus user browsing, plus exploit reliability across Chrome's hardening. That's still serious because Chrome is everywhere and sandbox escapes are valuable in exploit chains, but for patch scheduling this is closer to a chain amplifier than an urgent single-bug crisis.

"Treat this as a chainable sandbox escape, not a standalone internet-to-endpoint critical."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on attacker-controlled web content

The operator needs the user to browse to a malicious page or embedded content. The weaponized tool at this stage is just a crafted HTML/JS payload, but this CVE does nothing by itself from that position. A separate browser bug is needed to get code execution inside the renderer first.
Conditions required:
  • Victim uses vulnerable Chrome before 149.0.7827.53/54
  • Victim visits attacker-controlled content
  • Attacker has a separate renderer-compromise primitive
Where this breaks in practice:
  • User interaction is required
  • Safe Browsing, URL filtering, and mail/web isolation cut down delivery success
  • This CVE is not the initial code-exec primitive
Detection/coverage: Web proxies, DNS filtering, secure email gateways, and browser telemetry can often see the lure stage; vulnerability scanners generally cannot validate exploitability here.
STEP 02

Compromise the renderer with a companion bug

The operator then needs a renderer exploit chain, typically a memory corruption or UXSS issue, to gain execution inside Chrome's sandboxed renderer. The practical weapon is a custom companion exploit, not a public tool, and no public PoC for CVE-2026-11120 was found in primary-source review. Without this step, the Enterprise Reporting bug is inert.
Conditions required:
  • A working renderer exploit for the target Chrome build
  • Exploit reliability against the victim OS and browser channel
Where this breaks in practice:
  • Requires a second vulnerability or exploit technique
  • Browser exploit reliability is fragile across minor versions
  • Modern browser hardening raises development cost
Detection/coverage: EDR usually has poor visibility into renderer-only compromise unless it crashes or spawns a later-stage payload; crash telemetry and sandbox violation logs are more useful than network scanning.
STEP 03

Use Enterprise Reporting validation flaw to attempt sandbox escape

With renderer control established, the attacker abuses the Enterprise Reporting validation weakness to try to cross the sandbox boundary. The weaponized step is still the crafted HTML page, now paired with the companion renderer exploit. Because the vulnerable surface sits in Enterprise Reporting, this is most relevant on managed Chrome fleets; the exact reachability of the code path depends on product behavior and deployment specifics, so that narrowing is an inference, not an explicit vendor claim.
Conditions required:
  • Renderer already compromised
  • Target remains on a vulnerable Chrome build
  • Reachable Enterprise Reporting code path
Where this breaks in practice:
  • Exploit chain now depends on a component-specific escape
  • No public exploitation evidence or KEV listing
  • Unknown reliability outside lab conditions
Detection/coverage: There is no dependable commodity signature for this specific escape path. Browser crash spikes, anomalous chrome child process activity, and EDR detections after sandbox exit are the most realistic signals.
STEP 04

Execute post-escape payload on the endpoint

If the sandbox escape succeeds, the attacker can move from renderer confinement to code running with the browser's desktop privileges. The practical weapon here becomes the operator's post-exploitation framework or loader. That is the point where data theft, token theft, or lateral movement becomes operationally meaningful.
Conditions required:
  • Successful sandbox escape
  • Ability to run follow-on payloads under the user's context
Where this breaks in practice:
  • EDR, application control, and browser child-process restrictions can catch the breakout
  • User-context execution still may not equal admin rights
  • Post-exploitation noise is far easier to detect than the web trigger
Detection/coverage: EDR is strongest here: look for suspicious child processes from chrome.exe/Chrome, unusual module loads, file drops in user space, and browser-driven credential access.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation surfaced in the reviewed sources, and the CVE is not KEV-listed.
Proof-of-concept availabilityNo public PoC or GitHub exploit for CVE-2026-11120 was found in primary-source review; expect any real weaponization to live inside a private multi-bug chain.
EPSS0.00047 from the supplied intel — extremely low relative likelihood of observed exploitation over 30 days.
KEV statusNot listed in the CISA KEV catalog as of this assessment.
Vendor vs realityPrompt supplied a vendor baseline of CRITICAL 9.6 with AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H, but Google's own Chrome release notes label the bug Medium and the description itself says the attacker must have already compromised the renderer.
Affected versionsChrome prior to 149.0.7827.53; Google separately states fixed desktop builds are 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows/macOS.
Fixed versionsPatch to at least 149.0.7827.53 everywhere; for Windows/macOS, 149.0.7827.54 is also part of the fixed rollout.
Exposure populationChrome is ubiquitous, which keeps the floor above LOW. But this bug is a post-renderer-compromise sandbox escape, so the truly exposed population is much smaller than raw browser install count suggests.
Scanning / exposure dataInternet scanners like Shodan/Censys/FOFA are a bad fit for a client browser issue. Your source of truth is endpoint inventory, EDR, MDM/UEM, or Chrome enterprise reporting rather than external exposure scans.
Disclosure / reportingThe CVE record was published on 2026-06-04; Google says it was reported by Google on 2026-04-10 in the stable channel advisory.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.2/10)

The decisive factor is the hidden prerequisite: this is not an unauthenticated internet-to-endpoint bug by itself, but a sandbox escape that assumes prior renderer compromise. That turns a scary CVSS outcome into a much narrower real-world attack population, despite Chrome's huge install base.

HIGH Affected version range and fixed builds
HIGH Need for prior renderer compromise
MEDIUM Real-world narrowing from Enterprise Reporting deployment specifics
MEDIUM Absence of public PoC / active exploitation evidence

Why this verdict

  • Major downgrade for attacker position: the attack path is not true AV:N/PR:N in practice because the vendor description itself requires a pre-compromised renderer. That implies the operator already solved initial browser compromise with a separate bug, which is strong downward pressure from the 9.6 baseline.
  • Another downgrade for reachable population: while Chrome is everywhere, only the subset of users on vulnerable builds who can be driven to a malicious page and hit a working renderer exploit chain are realistically reachable. That is far smaller than 'all Chrome users on the internet.'
  • No threat acceleration signals: no KEV listing, no public exploitation evidence, and a very low supplied EPSS (0.00047) all argue against emergency treatment. This is a valuable chain component, not a field-proven mass-burn issue.

Why not higher?

I am not keeping this at HIGH or CRITICAL because the exploit chain starts with a prerequisite that most vendor CVSS readers miss: the attacker must already own the renderer. That means this CVE is post-initial-compromise inside the browser security model, not a one-bug drive-by full compromise. With no KEV listing or public exploitation evidence, the urgency simply does not support a top-tier bucket.

Why not lower?

I am not pushing this to LOW or IGNORE because Chrome is a massive enterprise attack surface and sandbox escapes matter. If an operator has or buys the companion renderer bug, this kind of flaw can turn a sandboxed browser foothold into endpoint impact quickly. For organizations managing large fleets, that keeps it above mere backlog trivia.

05 · Compensating Control

What to do — in priority order.

  1. Enforce Chrome auto-update compliance — Make browser-version compliance visible in UEM/EDR and force lagging endpoints onto fixed builds. For a MEDIUM verdict there is no mitigation SLA, but this is still the cleanest control while you work inside the 365-day remediation window.
  2. Prioritize companion renderer bugs above this CVE — If you are triaging multiple Chrome CVEs from the same release, patch memory-corruption and renderer-RCE candidates first because they are the missing first half of the chain. Do this immediately in your browser patch wave planning even though this specific CVE does not carry its own mitigation deadline.
  3. Tighten browser exploit guardrails — Keep Safe Browsing, web filtering, exploit protection, and EDR browser child-process rules enabled to make the initial renderer-compromise stage harder and the post-escape stage noisier. These are sensible compensations now, especially for outlier devices that cannot take the update promptly.
  4. Use managed-browser inventory as source of truth — Track vulnerable Chrome versions through MDM/UEM, EDR software inventory, or Chrome enterprise management rather than perimeter scans. That lets you close exceptions methodically during the normal remediation cycle.
What doesn't work
  • Perimeter vulnerability scanning doesn't help much; this is a client browser flaw, not an exposed server daemon.
  • A WAF is irrelevant because the vulnerable code runs on the endpoint inside Chrome, not behind your web applications.
  • Relying on CVSS alone will over-prioritize this item; the real-world exploit path is much narrower than the 9.6 label suggests.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your fleet tooling. Invoke it with python3 chrome_cve_2026_11120_check.py on macOS/Linux or py chrome_cve_2026_11120_check.py on Windows; no admin rights are usually needed, though registry access on locked-down Windows images may benefit from standard local read access.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# CVE-2026-11120 Chrome version check
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys

THRESHOLD = (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 cmp_ver(a, b):
    return (a > b) - (a < b)


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


def windows_versions():
    versions = []
    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"
            ])
            v = parse_version(out)
            if v:
                versions.append((path, v))

    reg_paths = [
        r'HKLM\Software\Google\Chrome\BLBeacon',
        r'HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon',
        r'HKCU\Software\Google\Chrome\BLBeacon',
    ]
    for key in reg_paths:
        out = run_cmd(['reg', 'query', key, '/v', 'version'])
        v = parse_version(out)
        if v:
            versions.append((key, v))
    return versions


def mac_versions():
    versions = []
    candidates = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
    ]
    for path in candidates:
        if os.path.exists(path):
            out = run_cmd([path, '--version'])
            v = parse_version(out)
            if v:
                versions.append((path, v))
    plist = '/Applications/Google Chrome.app/Contents/Info.plist'
    if os.path.exists(plist):
        out = run_cmd(['/usr/bin/defaults', 'read', plist.replace('/Info.plist', ''), 'CFBundleShortVersionString'])
        v = parse_version(out)
        if v:
            versions.append((plist, v))
    return versions


def linux_versions():
    versions = []
    candidates = [
        'google-chrome',
        'google-chrome-stable',
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable',
        'chromium',
        'chromium-browser',
    ]
    seen = set()
    for cmd in candidates:
        if cmd in seen:
            continue
        seen.add(cmd)
        out = run_cmd([cmd, '--version'])
        v = parse_version(out)
        if v:
            versions.append((cmd, v))
    return versions


def main():
    system = platform.system().lower()
    found = []

    if 'windows' in system:
        found = windows_versions()
    elif 'darwin' in system:
        found = mac_versions()
    else:
        found = linux_versions()

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

    # Deduplicate by version string while preserving evidence
    unique = []
    seen = set()
    for source, ver in found:
        key = (source, ver)
        if key not in seen:
            unique.append((source, ver))
            seen.add(key)

    vulnerable = []
    patched = []
    for source, ver in unique:
        if cmp_ver(ver, THRESHOLD) < 0:
            vulnerable.append((source, ver))
        else:
            patched.append((source, ver))

    if vulnerable:
        detail = '; '.join([f'{src}={".".join(map(str, ver))}' for src, ver in vulnerable])
        print(f'VULNERABLE: {detail}')
        sys.exit(1)
    else:
        detail = '; '.join([f'{src}={".".join(map(str, ver))}' for src, ver in patched])
        print(f'PATCHED: {detail}')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, do not treat CVE-2026-11120 like a drop-everything internet-facing critical. Use fleet inventory to find Chrome endpoints below 149.0.7827.53/54, confirm auto-update is working, and roll stragglers into the next normal browser update wave; there is no noisgate mitigation SLA — go straight to the 365-day remediation window. In practice, because browser updates are low-friction and this bug is a chain component, most mature teams should still clear it well before the noisgate remediation SLA limit of 365 days, while giving higher urgency to any accompanying Chrome renderer/RCE bugs from the same release.

Sources

  1. Google Chrome stable channel advisory
  2. Chromium issue 501467566
  3. CIRCL Vulnerability-Lookup entry for CVE-2026-11120
  4. Canadian Centre for Cyber Security advisory AV26-544
  5. Chrome Enterprise help: enable browser cloud reporting
  6. Chrome Enterprise policy: CloudProfileReportingEnabled
  7. CISA Known Exploited Vulnerabilities Catalog
  8. SecurityWeek coverage of Chrome 149 fixes
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.