This is a forged visitor badge at the front desk, not a master key to the building
CVE-2026-11169 is a UXSS/XML injection issue in Google Chrome before 149.0.7827.53 that lets a remote attacker get arbitrary script or HTML to run in the browser via a crafted XML file. In practice, the attacker still needs delivery: phishing, a malicious site, or some other way to get a user to open or render the attacker-controlled XML content in vulnerable Chrome builds on Windows, macOS, or Linux.
The raw 8.1/HIGH score overstates enterprise urgency. Yes, a browser-origin confusion bug can expose session data and let an attacker act as the user inside the browser, but the chain still depends on user interaction, browser reachability, and per-user session scope; there is no evidence of in-the-wild exploitation, no KEV listing, and the advisory itself describes the Chromium bug-class severity as Medium.
4 steps from start to impact.
Deliver a malicious XML lure
- Target runs Chrome older than
149.0.7827.53 - Attacker can send or host crafted XML content
- Target user opens the link, file, or page path that triggers XML handling
- Requires UI:R; fully hands-off exploitation is not indicated
- Enterprise mail/web filtering and Safe Browsing can cut down delivery volume
- Chrome auto-update shrinks the vulnerable window quickly in well-managed fleets
Trigger XML parsing into a UXSS condition
- The crafted XML reaches the vulnerable parsing path
- The target build contains the flawed XML implementation
- Exploit reliability may vary by rendering context and exact delivery path
- Chrome security features such as process isolation limit follow-on impact outside the compromised browser context
Run attacker-controlled script in the victim browser
- Victim has valuable authenticated web sessions
- Targeted applications do not fully blunt the attack with session protections, CSP, re-auth, or transaction signing
- Blast radius is user-session scoped, not fleet-wide by default
- HttpOnly cookies, step-up auth, CSP, and app-side anti-CSRF controls reduce practical payoff
- The attacker still has to monetize browser-level access; there is no direct sandbox escape in this CVE
Pivot into account abuse, not host takeover
- User is authenticated to sensitive SaaS or internal web apps
- The attacker can act quickly before tokens expire or sessions are revoked
- No direct evidence this bug alone gives OS compromise or broad lateral movement
- Modern identity controls can force re-authentication for sensitive actions
- A network perimeter firewall does not solve this; the exploit arrives as ordinary user web content or downloaded files.
- Treating this like a server exposure problem does not help; Shodan-style external attack-surface reduction is largely irrelevant because Chrome is the client.
- A generic AV signature-only approach is weak here because the malicious element is browser content/logic, not necessarily a dropped binary.
The supporting signals.
| In-the-wild status | No public exploitation evidence found in authoritative sources reviewed; this CVE is not KEV-listed. |
|---|---|
| PoC availability | No public PoC located during assessment. The Chromium issue reference exists but bug details are still restricted, which raises attacker friction. |
| EPSS | 0.00029 (~0.029%), which is very low and lines up with a low-likelihood, user-driven browser exploit path; percentile was not independently verified from a live FIRST CVE query during this assessment. |
| KEV status | Not present in the CISA KEV catalog as reviewed after disclosure; no KEV add date applies. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N — the big reality check is UI:R. That means this is not an unauthenticated, wormable server-side break; it needs victim interaction. |
| Affected versions | Google Chrome prior to 149.0.7827.53 on desktop platforms. The stable release post lists 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows/macOS. |
| Fixed versions | Treat 149.0.7827.53+ as fixed for vulnerability management. On Windows/macOS, Google published 149.0.7827.53/.54; on Linux, 149.0.7827.53. |
| Vendor vs reality | CISA-ADP/NVD show 8.1 HIGH, but the underlying Chrome description explicitly says "Chromium security severity: Medium". That mismatch matters because the reachable population is huge, but the exploit path is still user-driven and session-scoped. |
| Exposure / scanning | This is a client application, so there is no meaningful Shodan/Censys-style internet-exposed service surface to count. Your exposure question is simply: *how many endpoints are running old Chrome builds?* |
| Disclosure / reporter | Publicly disclosed in NVD on 2026-06-04; the Chrome stable update shipped on 2026-06-02. The release notes attribute this CVE to Google and show the issue was reported on 2026-04-13. |
Sources.
Why this verdict
- Downgrade for attacker position: this is remote content to browser exploitation, not unauthenticated remote code execution against a server or appliance.
- Downgrade for prerequisite chain:
UI:Rmeans the attacker needs a user to open or render the crafted XML content; that is real friction in enterprise deployments. - Downgrade for exposure model: Chrome is widely deployed, but the vulnerability is not internet-scannable infrastructure; reachable population is limited to users who can be lured.
- Downgrade for blast radius: the primary impact is browser-session compromise for one user at a time, not direct host takeover or default lateral movement.
- Downgrade for threat intel: there is no KEV listing, no public in-the-wild exploitation evidence, and the supplied EPSS is extremely low.
Why not higher?
If this were being actively exploited, KEV-listed, or paired with a sandbox escape or reliable auth-token theft against high-value SaaS workflows, the score would rise fast. But on the facts available, this is a single-bug browser trust issue that still depends on user interaction and does not by itself deliver OS-level compromise.
Why not lower?
This is still more than backlog lint. A successful UXSS bug in a mainstream browser can let an attacker act inside a victim's authenticated web context, which is enough for mailbox abuse, SaaS actions, and data theft. For enterprises with heavy browser-based workflows and SSO, that is meaningful operational risk.
Crowdsourced verification payload.
Run this on the target endpoint or through your EDR live-response shell with standard user rights; admin is not required. Save as check_cve_2026_11169.py and run python3 check_cve_2026_11169.py on macOS/Linux or py -3 check_cve_2026_11169.py on Windows. It looks for Google Chrome, extracts the installed version, and prints VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env python3
# check_cve_2026_11169.py
# Detects whether installed Google Chrome is vulnerable to CVE-2026-11169
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN / Chrome not found / parse failure
import os
import platform
import re
import subprocess
import sys
from pathlib import Path
FIXED_VERSION = (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 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 get_version_windows():
candidates = [
Path(os.environ.get('PROGRAMFILES', r'C:\Program Files')) / 'Google/Chrome/Application/chrome.exe',
Path(os.environ.get('PROGRAMFILES(X86)', r'C:\Program Files (x86)')) / 'Google/Chrome/Application/chrome.exe',
Path(os.environ.get('LOCALAPPDATA', '')) / 'Google/Chrome/Application/chrome.exe',
]
for exe in candidates:
if exe and exe.exists():
out = run_cmd(['powershell', '-NoProfile', '-Command', f"(Get-Item '{str(exe)}').VersionInfo.ProductVersion"])
ver = parse_version(out)
if ver:
return str(exe), ver
return None, None
def get_version_macos():
candidates = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
str(Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome')
]
for exe in candidates:
if Path(exe).exists():
out = run_cmd([exe, '--version'])
ver = parse_version(out)
if ver:
return exe, ver
return None, None
def get_version_linux():
commands = [
['google-chrome', '--version'],
['google-chrome-stable', '--version'],
['chromium-browser', '--version'],
['chromium', '--version'],
]
for cmd in commands:
out = run_cmd(cmd)
ver = parse_version(out)
if ver and ('chrome' in out.lower() or 'chromium' in out.lower()):
return ' '.join(cmd[:-1]), ver
candidates = [
'/opt/google/chrome/google-chrome',
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
]
for exe in candidates:
if Path(exe).exists():
out = run_cmd([exe, '--version'])
ver = parse_version(out)
if ver:
return exe, ver
return None, None
def compare_versions(installed, fixed):
if installed < fixed:
return 'VULNERABLE'
return 'PATCHED'
def main():
system = platform.system().lower()
path = None
version = None
if 'windows' in system:
path, version = get_version_windows()
elif 'darwin' in system:
path, version = get_version_macos()
elif 'linux' in system:
path, version = get_version_linux()
else:
print('UNKNOWN: unsupported platform')
sys.exit(2)
if not version:
print('UNKNOWN: Google Chrome not found or version unreadable')
sys.exit(2)
result = compare_versions(version, FIXED_VERSION)
version_str = '.'.join(str(x) for x in version)
fixed_str = '.'.join(str(x) for x in FIXED_VERSION)
print(f'{result}: installed={version_str} fixed={fixed_str} path={path}')
if result == 'PATCHED':
sys.exit(0)
elif result == 'VULNERABLE':
sys.exit(1)
else:
sys.exit(2)
if __name__ == '__main__':
main()