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

Inappropriate implementation in XML in Google Chrome prior to 149

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

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.

"This is a browser trust-bypass bug, not a hands-off enterprise-wide break-in"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a malicious XML lure

The attacker uses a phishing kit, chat lure, or watering-hole page to get a target onto attacker-controlled content that serves a crafted XML file. The bug is network-reachable in the sense that content can be delivered over the web, but it is not a service-side unauthenticated remote exploit against a server fleet.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Version scanners and software inventory can find outdated Chrome reliably; exploit-attempt detection is weak because the trigger is content-level and may look like ordinary document/web traffic.
STEP 02

Trigger XML parsing into a UXSS condition

The weaponized payload abuses Chrome's XML implementation to break expected content/origin handling and inject arbitrary script or HTML. This is a browser trust-boundary failure, not code execution on the host OS.
Conditions required:
  • The crafted XML reaches the vulnerable parsing path
  • The target build contains the flawed XML implementation
Where this breaks in practice:
  • 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
Detection/coverage: Network IDS is unlikely to have strong signatures unless a PoC becomes public; sandbox detonation may catch obviously weaponized lures, but coverage will be inconsistent.
STEP 03

Run attacker-controlled script in the victim browser

Once the UXSS lands, the attacker can execute script or inject HTML in the victim's browser session. That enables cookie theft where protections permit it, DOM access, transaction abuse, or acting as the logged-in user against web apps open in that browser context.
Conditions required:
  • Victim has valuable authenticated web sessions
  • Targeted applications do not fully blunt the attack with session protections, CSP, re-auth, or transaction signing
Where this breaks in practice:
  • 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
Detection/coverage: EDR can sometimes see suspicious browser child-process or credential-theft follow-on, but the UXSS itself often leaves sparse host telemetry.
STEP 04

Pivot into account abuse, not host takeover

The practical outcome is browser-session compromise: data theft from rendered pages, webmail/SSO abuse, or fraudulent actions in SaaS apps. Any move beyond that usually needs a second bug, stolen credentials, or weak downstream app controls.
Conditions required:
  • User is authenticated to sensitive SaaS or internal web apps
  • The attacker can act quickly before tokens expire or sessions are revoked
Where this breaks in practice:
  • No direct evidence this bug alone gives OS compromise or broad lateral movement
  • Modern identity controls can force re-authentication for sensitive actions
Detection/coverage: Best detection is downstream: anomalous SaaS activity, impossible travel, new OAuth grants, mailbox rule creation, or unusual session reuse.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found in authoritative sources reviewed; this CVE is not KEV-listed.
PoC availabilityNo public PoC located during assessment. The Chromium issue reference exists but bug details are still restricted, which raises attacker friction.
EPSS0.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 statusNot present in the CISA KEV catalog as reviewed after disclosure; no KEV add date applies.
CVSS vectorCVSS: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 versionsGoogle 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 versionsTreat 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 realityCISA-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 / scanningThis 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 / reporterPublicly 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.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.9/10)

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.

HIGH Version range and fixed build identification
MEDIUM Exploit-chain practicality without a public PoC
HIGH Severity downgrade driven by `UI:R` and client-side blast radius

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:R means 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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/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()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, treat this as a browser fleet hygiene issue rather than an incident-grade emergency: inventory endpoints still below 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

  1. NVD CVE-2026-11169
  2. Chrome Releases: Stable Channel Update for Desktop (June 2, 2026)
  3. Chromium issue reference 502285273
  4. Chromium Security
  5. Chromium Site Isolation overview
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS overview
  8. FIRST EPSS API documentation
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.