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

Inappropriate implementation in Printing in Google Chrome prior to 149

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

This is a second-story window problem after the burglar is already inside the house

CVE-2026-11093 is a Chrome Printing flaw caused by inappropriate implementation / input handling (CWE-20). Per the user-supplied intel, it affects Google Chrome before 149.0.7827.53, and the June 2026 Chrome security train shipped fixes as 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows/macOS, with 148.0.7778.254 available on the Extended Stable channel for Windows/macOS. The important operational detail is the prerequisite baked into the description: the attacker must already have compromised the renderer and then drive a printing code path.

paragraphs

"Not a front-door bug: it only matters after the attacker already owns Chrome's renderer."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Land a separate renderer exploit

The attacker first needs a different Chrome bug that gets code execution or equivalent control inside the renderer sandbox. There is no public tool chain tied to this CVE; weaponization would require a custom stage-1 exploit or reuse of another browser vulnerability. In practice, CVE-2026-11093 is not the initial access vector; it is the *follow-on* move in a chain.
Conditions required:
  • Victim is running vulnerable Chrome
  • Victim visits attacker-controlled content
  • Attacker has a separate renderer-compromise primitive
Where this breaks in practice:
  • This CVE is useless without stage-1 browser exploitation
  • No public exploit or turnkey PoC was found in the checked sources
  • Modern browser hardening and rapid auto-update make renderer bugs short-lived
Detection/coverage: Network scanners will not find this. Detection is mostly indirect: browser exploit telemetry, crash spikes, exploit protection alerts, or EDR signals around anomalous chrome behavior.
STEP 02

Abuse the printing path from the compromised renderer

From the already-compromised renderer, the attacker drives a crafted HTML/print flow into the vulnerable Printing implementation. Based on the supplied CVSS (C:H/I:N/A:N), the most likely business impact is confidentiality loss, not full host compromise. The missing truth in the vendor-style score is that the renderer-compromise prerequisite is a major real-world gate.
Conditions required:
  • Printing-related code path is reachable in the victim session
  • The crafted page can trigger the relevant print behavior
  • The vulnerable code path still exists on the installed platform/version
Where this breaks in practice:
  • Print-specific paths are narrower than generic HTML parsing bugs
  • Cross-platform behavior differs across Linux, Windows, and macOS release trains
  • Public technical details remain limited because Chromium bug records are typically restricted at disclosure
Detection/coverage: Again mostly version-based. Vulnerability scanners can only flag installed Chrome versions; they cannot safely simulate exploitation of this client-side path.
STEP 03

Extract data or cross a browser boundary

If exploitation succeeds, the attacker can likely read data that the renderer should not have been able to access. That is serious in a targeted intrusion, especially against high-value browsing sessions, but it is still a post-compromise amplifier rather than a mass-exploitation starter. For enterprise prioritization, that keeps this out of the urgent bucket absent active exploitation evidence.
Conditions required:
  • Useful secrets are present in the browser context or reachable through the flaw
  • Attacker can exfiltrate the harvested data
Where this breaks in practice:
  • Impact appears limited to confidentiality in the supplied vector
  • Blast radius is tied to the victim session, not broad unauthenticated server exposure
  • EDR, browser isolation, or VDI containment can reduce practical follow-on value
Detection/coverage: Look for browser-driven access to unusual internal content, abnormal child-process behavior, or exfil patterns after suspicious browsing events. There is no meaningful perimeter signature for the CVE itself.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found in the checked sources, and not listed in CISA KEV as of 2026-06-06.
Proof-of-concept availabilityNo public PoC or exploit kit located in the checked sources. That matters because this CVE still needs a separate renderer-compromise stage before it does anything useful.
EPSSUser-supplied EPSS is 0.00047 (~0.047% 30-day exploitation probability). That is very low modeled attacker interest and fits the lack of public exploitation noise.
KEV statusNo. The CVE is not present in the CISA KEV catalog.
Vendor score vs realityVendor severity MEDIUM 6.5 is still a bit generous operationally because the published vector does not capture the prior renderer-compromise requirement. In a real intrusion chain, that prerequisite is huge downward pressure.
CVSS vector interpretationCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N says *remote with user interaction, confidentiality-heavy, no integrity/availability impact*. What it misses is that exploitation is not direct from the web; the attacker must already be inside the renderer.
Affected versionsPer the supplied intel, Chrome prior to 149.0.7827.53. Public Chrome release advisories for the June 2026 security train indicate 149.0.7827.53/54 on Windows/macOS and 149.0.7827.53 on Linux.
Fixed versionsLinux: 149.0.7827.53 or later. Windows/macOS Stable: 149.0.7827.53/54 or later. Windows/macOS Extended Stable: 148.0.7778.254 per Chrome Releases / Cyber Centre advisories.
Scanning / exposure dataShodan/Censys/FOFA are basically irrelevant here: Chrome Desktop is a client app, not an internet-listening service. Your exposure metric is managed endpoint count, especially browsers allowed to reach untrusted sites.
Disclosure / attributionDisclosed 2026-06-04. The checked public advisory pages do not clearly attribute an external finder, so treat reporter attribution as not publicly established from available sources.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (4.3/10)

The single decisive factor is the prior renderer-compromise requirement: this bug is not a direct web-to-host path, it is a post-initial-browser-exploitation chain component. That sharply narrows both the reachable population and the number of attackers who can operationalize it, even though Chrome itself is ubiquitous.

HIGH Downgrade rationale driven by the renderer-compromise prerequisite
MEDIUM Exact exploit impact beyond confidentiality due to limited public bug detail

Why this verdict

  • Start from 6.5, then subtract hard for attacker position: this CVE requires the attacker to have already compromised Chrome's renderer, which implies a prior exploit stage and makes it a chained post-compromise bug, not a first-hop flaw.
  • User interaction still matters: the victim must browse attacker-controlled content and hit the right print-related path, so this is not a no-click enterprise-wide exposure event.
  • Threat intel is cold: no KEV, no public exploitation evidence found, and EPSS 0.00047 all argue against emergency treatment.

Why not higher?

It is not higher because the reachable population is narrower than the CVSS suggests. An attacker needs a separate renderer foothold first, and the checked public sources do not show active exploitation, KEV listing, or public weaponization that would justify a high-priority override.

Why not lower?

It is not lower because Chrome is everywhere and chained browser exploitation is still strategically valuable against high-value users. Even a confidentiality-focused post-renderer bug can matter in targeted operations, especially where browsers handle internal web apps, SSO sessions, or sensitive documents.

05 · Compensating Control

What to do — in priority order.

  1. Enforce Chrome auto-update — Make sure enterprise policy is actually keeping Chrome on the current Stable or Extended Stable channel. For a MEDIUM verdict there is no mitigation SLA; use this as routine risk reduction while driving remediation within 365 days.
  2. Contain risky browsing — Push privileged admins, finance users, and other high-value populations into browser isolation, disposable VDI sessions, or separate hardened browsing profiles. This shrinks the payoff of any renderer-plus-follow-on chain; there is no mitigation SLA — go straight to the 365-day remediation window.
  3. Hunt for abnormal Chrome behavior — Use EDR to watch for suspicious chrome child processes, unusual file access, and exfiltration immediately after browsing events. This does not patch the bug, but it is the right detective layer for a client-side chained exploit while you patch within 365 days.
  4. Prioritize externally browsing endpoints — Patch kiosks, jump boxes, developer workstations, and users with broad internet access before lightly-used internal-only endpoints. The vulnerability's practical exposure is tied to where untrusted content is rendered; remediation is still due within 365 days.
What doesn't work
  • A WAF does not help much because the vulnerable target is the client browser, not your web server.
  • Perimeter vulnerability scanners will not prove safety here; they can at best check versioning through endpoint inventory, not exploit the client-side print path.
  • Generic email gateway controls are only indirectly useful; the core delivery vector is any attacker-controlled web content the user opens in Chrome.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or via your software-distribution / EDR remote execution tool. Invoke it as python3 chrome_cve_2026_11093_check.py; it needs no admin privileges if Chrome is installed in standard locations, though registry access on Windows works more reliably in a normal user session than from a restricted service context.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# chrome_cve_2026_11093_check.py
# Detect whether Google Chrome Desktop is patched for CVE-2026-11093 by version.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import plistlib
import re
import subprocess
import sys

TARGET_LINUX = (149, 0, 7827, 53)
TARGET_STABLE = (149, 0, 7827, 53)
TARGET_EXTENDED = (148, 0, 7778, 254)


def parse_version(s):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', s or '')
    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 '') + ' ' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def get_version_linux():
    candidates = [
        ['google-chrome', '--version'],
        ['google-chrome-stable', '--version'],
        ['chromium', '--version'],
        ['chromium-browser', '--version'],
    ]
    for cmd in candidates:
        out = run_cmd(cmd)
        ver = parse_version(out)
        if ver:
            return ver, ' '.join(cmd)
    return None, ''


def get_version_macos():
    paths = [
        '/Applications/Google Chrome.app/Contents/Info.plist',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/Info.plist'),
    ]
    for path in paths:
        if os.path.exists(path):
            try:
                with open(path, 'rb') as f:
                    data = plistlib.load(f)
                ver = parse_version(data.get('KSVersion', '') or data.get('CFBundleShortVersionString', ''))
                if ver:
                    return ver, path
            except Exception:
                pass
    return None, ''


def get_version_windows():
    try:
        import winreg
    except Exception:
        winreg = None

    reg_paths = [
        (0x80000002, r'SOFTWARE\Google\Chrome\BLBeacon'),
        (0x80000001, r'SOFTWARE\Google\Chrome\BLBeacon'),
        (0x80000002, r'SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon'),
    ]

    if winreg is not None:
        for hive_const, subkey in reg_paths:
            try:
                hive = hive_const
                key = winreg.OpenKey(hive, subkey)
                version, _ = winreg.QueryValueEx(key, 'version')
                ver = parse_version(version)
                if ver:
                    return ver, 'registry:' + subkey
            except Exception:
                pass

    paths = [
        os.path.expandvars(r'%ProgramFiles%\Google\Chrome\Application\chrome.exe'),
        os.path.expandvars(r'%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe'),
        os.path.expandvars(r'%LocalAppData%\Google\Chrome\Application\chrome.exe'),
    ]
    for path in paths:
        if os.path.exists(path):
            out = run_cmd([path, '--version'])
            ver = parse_version(out)
            if ver:
                return ver, path
    return None, ''


def assess(ver, system_name):
    if ver is None:
        return 'UNKNOWN', 2, 'Could not determine Chrome version'

    if system_name == 'Linux':
        if cmp_ver(ver, TARGET_LINUX) >= 0:
            return 'PATCHED', 0, 'Chrome version meets Linux fixed version'
        return 'VULNERABLE', 1, 'Chrome version is below Linux fixed version 149.0.7827.53'

    if system_name in ('Darwin', 'Windows'):
        if cmp_ver(ver, TARGET_STABLE) >= 0:
            return 'PATCHED', 0, 'Chrome version meets Stable fixed version'
        if ver[:3] == TARGET_EXTENDED[:3] and cmp_ver(ver, TARGET_EXTENDED) >= 0:
            return 'PATCHED', 0, 'Chrome version meets Extended Stable fixed version'
        return 'VULNERABLE', 1, 'Chrome version is below fixed Stable/Extended Stable versions'

    return 'UNKNOWN', 2, 'Unsupported platform'


def main():
    sysname = platform.system()
    ver = None
    source = ''

    if sysname == 'Linux':
        ver, source = get_version_linux()
    elif sysname == 'Darwin':
        ver, source = get_version_macos()
    elif sysname == 'Windows':
        ver, source = get_version_windows()
    else:
        print('UNKNOWN')
        sys.exit(2)

    status, rc, reason = assess(ver, sysname)
    if ver:
        print(f'{status} - detected Chrome version {".".join(map(str, ver))} via {source} - {reason}')
    else:
        print(f'{status} - {reason}')
    sys.exit(rc)


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

If you remember one thing.

TL;DR
Monday morning, do not treat this like a fleet-wide fire drill. Put vulnerable Chrome endpoints into your normal browser-update campaign, verify which devices are still below 149.0.7827.53 (or below 148.0.7778.254 on Windows/macOS Extended Stable), and focus first on users who browse untrusted content or hold sensitive sessions. For a MEDIUM noisgate verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window; there is also no evidence here to justify an hours-level emergency exception. Your noisgate remediation SLA is ≤365 days, but in practice you should clear browser stragglers much faster through your evergreen update process rather than carrying this as backlog for a year.

Sources

  1. Chrome Releases - Stable Channel Update for Desktop
  2. Chrome Releases homepage
  3. Canadian Centre for Cyber Security advisory AV26-544
  4. GovCERT.HK Google Chrome alert
  5. CISA Known Exploited Vulnerabilities catalog
  6. FIRST EPSS overview
  7. FIRST EPSS API documentation
  8. Quanteta CVE tracker index
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.