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
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. |
noisgate verdict.
The single biggest downgrade driver is attacker position: this bug still requires user interaction with crafted content in a vulnerable browser, so it is not a direct server-side initial-access path into your estate. The impact can be serious for an individual user's web sessions, but the lack of exploitation evidence and the per-session blast radius keep it out of HIGH.
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.
What to do — in priority order.
- Enforce browser auto-update — Make sure Chrome stable updates are centrally enforced through enterprise policy so vulnerable builds age out naturally. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but browser controls should still keep drift low on day-to-day operations.
- Block direct XML launch paths from untrusted sources — Use mail gateway, web proxy, and endpoint controls to reduce delivery of untrusted XML attachments and downloads where business use is rare. This does not replace patching, but it raises the cost of phishing-style exploitation during the remediation window.
- Harden SaaS sessions — Apply re-authentication, conditional access, and transaction protections for sensitive web apps so a browser-session bug is less valuable. This matters because the most realistic post-exploit outcome here is acting as the logged-in user.
- Monitor for browser-driven identity abuse — Tune detections around mailbox rule creation, impossible travel, unusual OAuth grants, and abnormal SaaS actions originating from user sessions. That is where this CVE is most likely to show up operationally if exploited.
- 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.
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()
If you remember one thing.
149.0.7827.53, verify auto-update policy is actually working, and roll the fixed build through your normal browser channel. For a MEDIUM reassessment there is no noisgate mitigation SLA — go straight to the 365-day remediation window; the noisgate remediation SLA is ≤365 days, though most enterprises should finish far sooner simply by enforcing Chrome auto-update and cleaning up version drift.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.