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

CVE-2026-11027 is an input-validation flaw in Chrome's Glic component affecting builds before 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows and macOS. Based on the vendor wording you supplied and Chrome's architecture, the realistic abuse case is not a clean one-bug drive-by; it is a browser-boundary weakness that becomes useful *after* an attacker has already gained control of a less-privileged browser context such as the renderer and can then push crafted input into a more-privileged Chrome component.

Google's MEDIUM/6.5 label is defensible in CVSS terms because Chrome is everywhere and the confidentiality impact could be meaningful. But for patch-priority in a 10,000-host enterprise, it overstates the operational urgency: the decisive friction is that the attacker likely needs a prior renderer compromise or equivalent browser foothold, which makes this a *chain multiplier* rather than an *initial access primitive*.

Why this verdict

• Major downgrade: likely requires prior renderer compromise — in Chrome's security model, renderer processes are sandboxed and reach privileged functionality through IPC, so this reads like a *post-browser-compromise* step rather than an initial access bug.
• Population narrowing: Glic is not the broadest browser attack surface — even though Chrome itself is ubiquitous, a component-specific flaw in a niche feature does not automatically deserve the full weight of Chrome's install base.
• Threat telemetry is cold — no KEV entry, no credible public exploitation, and an EPSS of 0.00047 all argue against spending emergency patch capital here.

Why not higher?

If this were a clean, one-click drive-by leading directly to browser or OS compromise, it would rate much higher because Chrome is everywhere. But the likely prerequisite of a separate renderer compromise compounds the friction dramatically, and the stated impact is confidentiality-only rather than full code execution or host takeover.

Why not lower?

This is still a remotely triggerable browser issue in a high-value application, and if chained by a capable actor it can meaningfully expose data. Chrome also has huge enterprise footprint, so even a niche chain-step bug deserves inventory validation and inclusion in the normal browser update cadence.

1. Force Chrome auto-update compliance — Make sure managed endpoints are actually ingesting current Stable or approved Enterprise channel updates, because browser vulnerabilities age badly when stragglers linger. For a LOW verdict there is no SLA; treat as backlog hygiene, but fold version enforcement into your next normal browser maintenance cycle.
2. Disable unneeded experimental browser features — If your estate enables preview or experimental Chrome capabilities, review and turn off anything not explicitly required, especially pilot-only AI or side-panel features. This is the cleanest compensating control when the vulnerable surface is a niche component; for LOW, handle it as routine hardening rather than an emergency action.
3. Prioritize browser isolation for high-risk users — Put admins, finance, and frequent spearphish targets behind stricter browsing controls such as remote browser isolation, tighter extension policy, and stronger web filtering. That reduces the chance of the prerequisite renderer-compromise stage, which is the real gate in this chain.
4. Hunt for browser exploit precursors, not just this CVE — Look for Chrome crash clusters, unusual renderer instability, suspicious extension installs, and post-click browsing to unknown domains. If this CVE matters in your environment, it will usually appear *after* evidence of some other browser-stage exploit attempt.

Run this on the target endpoint or through your software inventory agent. Invoke it with python3 check_cve_2026_11027.py on Windows, macOS, or Linux; no admin rights are required for a basic version check, but reading enterprise policy/flags may require access to user profile files.

#!/usr/bin/env python3
# check_cve_2026_11027.py
# Determine likely exposure to CVE-2026-11027 by checking local Chrome/Chromium version.
# Outputs one of: 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

FIX_WINDOWS_MAC = (149, 0, 7827, 53)  # Chrome post indicates .53/.54 on Win/Mac; .53 is minimum safe floor
FIX_LINUX = (149, 0, 7827, 53)

CANDIDATES = {
    'Windows': [
        r'C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe',
        r'C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe',
        r'C:\\Program Files\\Chromium\\Application\\chrome.exe',
        r'C:\\Program Files (x86)\\Chromium\\Application\\chrome.exe',
    ],
    'Darwin': [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        '/Applications/Chromium.app/Contents/MacOS/Chromium',
    ],
    'Linux': [
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable',
        '/usr/bin/chromium',
        '/usr/bin/chromium-browser',
        '/snap/bin/chromium',
    ],
}

VERSION_RE = re.compile(r'(\d+)\.(\d+)\.(\d+)\.(\d+)')


def parse_version(s):
    m = VERSION_RE.search(s)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def run_version(binary):
    try:
        cp = subprocess.run([binary, '--version'], capture_output=True, text=True, timeout=8)
        out = (cp.stdout or '') + ' ' + (cp.stderr or '')
        return parse_version(out)
    except Exception:
        return None


def find_binary():
    system = platform.system()
    # Check PATH first
    for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome']:
        p = shutil.which(name)
        if p:
            v = run_version(p)
            if v:
                return p, v
    # Check well-known locations
    for p in CANDIDATES.get(system, []):
        if Path(p).exists():
            v = run_version(p)
            if v:
                return p, v
    return None, None


def version_lt(a, b):
    return a < b


def main():
    system = platform.system()
    binary, version = find_binary()

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

    if system == 'Linux':
        fixed = FIX_LINUX
    elif system in ('Windows', 'Darwin'):
        fixed = FIX_WINDOWS_MAC
    else:
        print(f'UNKNOWN: Unsupported platform {system}; detected version {version} from {binary}')
        sys.exit(2)

    version_str = '.'.join(map(str, version))
    fixed_str = '.'.join(map(str, fixed))

    if version_lt(version, fixed):
        print(f'VULNERABLE: detected {version_str} at {binary}; fixed floor is {fixed_str}')
        sys.exit(1)
    else:
        print(f'PATCHED: detected {version_str} at {binary}; fixed floor is {fixed_str}')
        sys.exit(0)


if __name__ == '__main__':
    main()

Sources

1. Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
2. Chrome Releases - Extended Stable Updates for Desktop (148.0.7778.254)
3. Chrome Enterprise - Release channels
4. Chromium multi-process architecture
5. Chromium sandbox design
6. Chromium process sandboxes by platform
7. CISA Known Exploited Vulnerabilities Catalog
8. FIRST EPSS API documentation