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

CVE-2026-11022 is an *improper input validation* flaw in Chrome DevTools affecting Chrome versions before 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows and macOS. Google labels it Medium, and the user-supplied description fragment indicates the attacker already needs a prior foothold in the browser (who had compromised ...). Based on that fragment and adjacent Chrome DevTools cases from the same release train, this looks like a *post-renderer-compromise* trust-boundary failure inside the browser rather than a clean one-shot remote compromise.

That matters more than the component name. DevTools bugs sound scary, but the real question is whether this gets an attacker from *the internet* to *your endpoint* by itself. It does not. The decisive friction is the prerequisite: the attacker likely needs a separate renderer compromise first, which means this CVE is mostly valuable as a *chain amplifier* for an existing browser exploit, not as an initial-access primitive.

Why this verdict

• Downward pressure: requires attacker position beyond initial access — the available description fragment strongly suggests the attacker already needs a compromised renderer process, which implies a prior exploit stage.
• Downward pressure: narrow reachable population per exploit attempt — even though Chrome is everywhere, only systems that are both unpatched *and* successfully hit with a separate renderer exploit can benefit the attacker.
• Downward pressure: no KEV, no public PoC, near-floor EPSS — the telemetry picture does not support urgent internet-scale exploitation pressure right now.
• Upward pressure: browser ubiquity and identity-rich sessions — if chained successfully, browser-boundary erosion can expose SaaS data, tokens, and authenticated cross-origin content across a very large enterprise population.

Why not higher?

It does not present as a standalone remote compromise path, and the attacker likely needs a separate renderer exploit first. That compounding prerequisite is exactly the kind of friction that should stop this from being scored like a primary browser RCE or sandbox escape.

Why not lower?

Chrome is ubiquitous, and post-renderer-compromise browser-boundary bugs are still useful in real exploit chains. Even without OS-level takeover, cross-origin data access in enterprise browser sessions can expose SSO-backed business data and make a separate browser exploit materially more valuable.

1. Force browser auto-update health checks — Use Chrome Enterprise reporting to identify pinned, stale, or offline browsers and verify they are moving to 149.0.7827.53+. For a MEDIUM finding there is no mitigation SLA — go straight to the 365-day remediation window, but browsers should usually be cleaned up far faster as part of normal fleet hygiene.
2. Reduce risky extension surface — Tighten extension allowlisting and remove unnecessary high-permission extensions, especially in privileged user groups. This does not fix the bug, but it reduces adjacent browser abuse paths while you remediate within the 365-day remediation window.
3. Enable Chrome browser reporting — Turn on managed browser reporting so you can see exact version distribution and prove closure. For MEDIUM, there is no mitigation SLA, so use reporting to drive remediation completeness rather than emergency block actions.
4. Harden session replay resistance — Prioritize short session lifetimes, phishing-resistant MFA, and conditional access for high-value SaaS apps. That limits the payoff if a browser-side data leak is chained before patch completion in the 365-day remediation window.

Run this on the target endpoint or through your software-distribution/remote-exec platform. Invoke it with python3 chrome_cve_2026_11022_check.py; no admin rights are required if Chrome is installed in standard locations, though broader filesystem access helps on locked-down hosts.

#!/usr/bin/env python3
# chrome_cve_2026_11022_check.py
# Check local Google Chrome version against CVE-2026-11022 fixed versions.
# Output: VULNERABLE / PATCHED / UNKNOWN
# 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_LINUX = (149, 0, 7827, 53)
FIXED_WINMAC = (149, 0, 7827, 53)  # 53/54 are fixed; >=53 is acceptable


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


def version_gte(a, b):
    return a >= b


def run_cmd(cmd):
    try:
        out = subprocess.check_output(cmd, stderr=subprocess.STDOUT, text=True, timeout=10)
        return out.strip()
    except Exception:
        return None


def detect_linux():
    candidates = [
        shutil.which('google-chrome'),
        shutil.which('google-chrome-stable'),
        shutil.which('chrome'),
        '/opt/google/chrome/chrome',
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable',
    ]
    for c in candidates:
        if c and Path(c).exists():
            out = run_cmd([c, '--version'])
            ver = parse_version(out)
            if ver:
                return c, ver
    return None, None


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


def detect_windows():
    roots = [
        os.environ.get('ProgramFiles'),
        os.environ.get('ProgramFiles(x86)'),
        os.environ.get('LocalAppData'),
    ]
    candidates = []
    for root in roots:
        if root:
            candidates.append(os.path.join(root, 'Google', 'Chrome', 'Application', 'chrome.exe'))

    for c in candidates:
        if Path(c).exists():
            version_file = os.path.join(os.path.dirname(c), 'chrome.VisualElementsManifest.xml')
            out = run_cmd(['powershell', '-NoProfile', '-Command', f"(Get-Item '{c}').VersionInfo.ProductVersion"])
            ver = parse_version(out)
            if ver:
                return c, ver
    return None, None


def main():
    system = platform.system().lower()

    path = None
    ver = None
    fixed = None

    if 'linux' in system:
        path, ver = detect_linux()
        fixed = FIXED_LINUX
    elif 'darwin' in system:
        path, ver = detect_macos()
        fixed = FIXED_WINMAC
    elif 'windows' in system:
        path, ver = detect_windows()
        fixed = FIXED_WINMAC
    else:
        print('UNKNOWN: unsupported operating system')
        sys.exit(2)

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

    if version_gte(ver, fixed):
        print(f'PATCHED: Chrome version {".".join(map(str, ver))} at {path}')
        sys.exit(0)
    else:
        print(f'VULNERABLE: Chrome version {".".join(map(str, ver))} at {path}')
        sys.exit(1)


if __name__ == '__main__':
    main()

Sources

1. Chrome Releases 2026 archive entry showing CVE-2026-11022 severity and report date
2. Chrome Stable Channel Update for Desktop 149 release
3. Chrome Early Stable Update for Desktop 149.0.7827.53/.54
4. Chrome Enterprise: View Chrome version details
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS API documentation
7. FIRST EPSS data and stats
8. Research context on Chrome DevTools/Debugger abuse paths