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
3 steps from start to impact.
Land a separate renderer exploit
- Victim is running vulnerable Chrome
- Victim visits attacker-controlled content
- Attacker has a separate renderer-compromise primitive
- 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
chrome behavior.Abuse the printing path from the compromised renderer
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.- 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
- 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
Extract data or cross a browser boundary
- Useful secrets are present in the browser context or reachable through the flaw
- Attacker can exfiltrate the harvested data
- 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
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found in the checked sources, and not listed in CISA KEV as of 2026-06-06. |
|---|---|
| Proof-of-concept availability | No 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. |
| EPSS | User-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 status | No. The CVE is not present in the CISA KEV catalog. |
| Vendor score vs reality | Vendor 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 interpretation | CVSS: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 versions | Per 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 versions | Linux: 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 data | Shodan/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 / attribution | Disclosed 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. |
noisgate verdict.
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.
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.
What to do — in priority order.
- 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.
- 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.
- Hunt for abnormal Chrome behavior — Use EDR to watch for suspicious
chromechild 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. - 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.
- 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.
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.
#!/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()
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.