This is a pickpocket bug, not a crowbar
CVE-2026-11196 is a Chrome XML/XSLT parsing flaw classified as type confusion (CWE-843). A remote attacker can feed a victim crafted XML content and, if the victim opens it in vulnerable Chrome, potentially read sensitive data from browser process memory. The affected range is Chrome versions prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/54 on Windows and macOS; Google shipped the stable fix on 2026-06-02 and the CVE record was published on 2026-06-04.
The vendor's MEDIUM 6.5 is basically fair. Yes, Chrome is everywhere and the attacker can deliver this over the internet, but the chain still depends on user interaction and the published impact is *information disclosure*, not code execution or sandbox escape. In real enterprise fleets, that combination usually lands in the "patch through normal browser governance, but don't panic" bucket.
4 steps from start to impact.
Deliver crafted XML/XSLT content
phishing kit or a hostile web page; nothing about this CVE requires prior authentication or internal network position.- Target is running vulnerable Chrome before
149.0.7827.53 - Attacker can reach the user over email, chat, web, or downloaded content
- Chrome is permitted to render or open the attacker-controlled XML/XSLT content
- Email security, Safe Browsing, and web filtering regularly kill the delivery path
- Many users do not routinely open standalone XML/XSLT content
- Enterprise browsers often warn on unusual downloads or external file opens
Trigger the parser bug in the browser
external/wpt/xml/xslt/xslt-type-confusion-crash.html, which strongly suggests an XSLT/XML parser edge case rather than a broadly reachable everyday browsing primitive.- Victim actually opens the malicious content in Chrome
- The specific vulnerable parser path is exercised
- This is narrower than a generic HTML/JS drive-by path
- Google kept bug details restricted while the update rolled out, so exploit developers have less turnkey detail
- Parser edge cases often prove less reliable across platforms and builds than headline browser RCEs
Convert memory disclosure into useful data
Chrome renderer/process memory itself, and that is a much messier post-trigger step than simply getting code execution.- The flaw yields attacker-observable memory disclosure
- Sensitive material is resident in the affected browser process at the time
- The attacker can exfiltrate or otherwise recover the leaked bytes
- Information disclosure bugs are often noisy, partial, or inconsistent
- Site isolation, process separation, and modern browser hardening reduce the odds of high-value cross-site secrets being adjacent and readable
- A leak without clean parsing or exfiltration logic often dies as a lab-only bug
Operationalize the stolen data
session hijacking, credential replay, or targeted follow-on phishing.- Recovered data contains actionable secrets
- Those secrets remain valid long enough to abuse
- Leaked fragments may be incomplete or stale
- MFA, short-lived tokens, and conditional access can blunt the value of stolen browser artifacts
- Blast radius is usually one user session, not a fleet-wide takeover primitive
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found in the sources reviewed, and the CVE is not listed in CISA KEV at time of review. |
|---|---|
| Proof-of-concept availability | No public exploit or PoC surfaced in the reviewed results. Google notes bug details may stay restricted until most users are updated. |
| EPSS | 0.035% (11th percentile) as shown by the GitHub advisory on 2026-06-05; that is low and consistent with a low-observed exploitation likelihood. |
| KEV status | Not KEV-listed; no CISA due date applies. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — remote and low-complexity, but user interaction is mandatory and the published impact is confidentiality-only. |
| Affected versions | Chrome before 149.0.7827.53. Google's desktop stable post specifies fixed builds of 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows/macOS. |
| Fixed versions | Upgrade to Chrome 149 stable or later. For managed estates, verify your channel pinning and relaunch policy so users actually move onto the fixed build. |
| Exposure/scanning reality | This is a client-side browser bug. Shodan/Censys-style internet scanning does not meaningfully enumerate vulnerable endpoints, so exposure has to come from asset inventory, EDR/software inventory, or Chrome Enterprise reporting. |
| Disclosure timeline | Stable fix released 2026-06-02; CVE record published 2026-06-04; GitHub advisory published 2026-06-05. |
| Researcher / reporting signal | The individual Chromium bug remains restricted, but public Chromium test references tie crbug.com/503879106 to xml/xslt/xslt-type-confusion-crash, pointing to the XML/XSLT parser path. |
noisgate verdict.
The decisive factor is mandatory user interaction combined with confidentiality-only impact. This is internet-deliverable and Chrome is ubiquitous, but the chain is still a click-to-trigger data leak, not a reliable enterprise-compromise primitive.
Why this verdict
- User interaction cuts the chain: attacker position starts as unauthenticated remote, but exploitation still requires the victim to open attacker-controlled XML/XSLT content. That prerequisite implies dependence on phishing, download, or lure success, and modern email/web controls should stop a meaningful fraction of attempts.
- Impact is a leak, not code exec: the published outcome is sensitive memory disclosure from Chrome process memory. That is materially less operationally dangerous than an RCE or sandbox escape with the same delivery path.
- Population is huge, but exposure is not mass-scannable: Chrome is widely deployed, which supports keeping this above LOW, yet there is no internet-facing service to enumerate and spray at scale. Real defenders have to manage this as endpoint software hygiene, not perimeter emergency response.
- Threat intel is cold: no KEV listing, no public exploitation evidence, no public PoC found, and the EPSS signal is low. Those are all downward pressures from the 6.5 baseline.
- Enterprise update mechanics help defenders: Chrome has mature auto-update and relaunch controls in managed environments. That doesn't erase the bug, but it reduces the size and dwell time of the vulnerable population when browser governance is healthy.
Why not higher?
There is no evidence here of code execution, sandbox escape, wormability, or active exploitation. The exploit chain narrows immediately at the user-interaction step, then narrows again because the attacker still has to convert a memory disclosure into useful secrets and then into business impact.
Why not lower?
I would not drop this to LOW because Chrome is one of the most exposed applications in the fleet and remote delivery is trivial. Even a confidentiality-only browser bug can matter for targeted users if the leaked process memory includes tokens, page contents, or other sensitive session material.
What to do — in priority order.
- Keep Chrome auto-update on — Validate that managed browsers are not pinned behind the fixed build and that relaunch prompts are enforced. For a
MEDIUMverdict there is no mitigation SLA — go straight to the 365-day remediation window, but in practice this should simply ride your normal Chrome update channel without creating stragglers. - Block untrusted XML attachments — Tune email and web controls to quarantine or warn on unsolicited
.xml,.xsl, and similar content from external sources. There is no mitigation SLA for aMEDIUMfinding, but this is a cheap exposure reducer while the fleet naturally rolls onto the patched browser build. - Enforce relaunch compliance — A lot of Chrome fleets look patched in inventory while users keep old renderer processes alive for days. Use browser relaunch notifications or device restart policy so the fixed binary actually becomes the running binary; with
MEDIUM, there is no mitigation SLA — go straight to remediation tracking. - Watch high-risk user groups — Prioritize executives, finance, admins, developers, and users regularly targeted by phishing for version verification and suspicious browser event review. This is where a memory-disclosure bug is most likely to translate into something that matters.
- A WAF does not help much here because the vulnerable component is the client browser, not your web server.
- External perimeter vulnerability scanning will not tell you who is exposed; this is not an internet-facing daemon you can fingerprint accurately.
- Generic network segmentation does little for the initial trigger because the attacker can reach the user through normal web or email channels.
Crowdsourced verification payload.
Run this on the target endpoint or through your endpoint management tooling. Invoke it as python3 chrome_cve_2026_11196_check.py; no admin rights are required, but the script needs permission to execute the local Chrome binary or read standard install paths. It checks common Windows, macOS, and Linux locations and prints VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env python3
# CVE-2026-11196 Chrome version check
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
FIXED = (149, 0, 7827, 53)
def parse_version(s):
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', s or '')
return tuple(map(int, m.groups())) if m else None
def version_ge(a, b):
return a >= b
def get_output(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 candidate_commands():
system = platform.system().lower()
cmds = []
if system == 'windows':
local = os.environ.get('LOCALAPPDATA', '')
pf = os.environ.get('PROGRAMFILES', '')
pf86 = os.environ.get('PROGRAMFILES(X86)', '')
paths = [
os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(pf, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(pf86, 'Google', 'Chrome', 'Application', 'chrome.exe'),
]
for p in paths:
if p and os.path.exists(p):
cmds.append([p, '--version'])
elif system == 'darwin':
paths = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
]
for p in paths:
if os.path.exists(p):
cmds.append([p, '--version'])
else:
names = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']
for name in names:
path = shutil.which(name)
if path:
cmds.append([path, '--version'])
linux_paths = [
'/opt/google/chrome/chrome',
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/snap/bin/chromium',
'/usr/bin/chromium',
'/usr/bin/chromium-browser',
]
for p in linux_paths:
if os.path.exists(p):
cmds.append([p, '--version'])
# de-duplicate while preserving order
seen = set()
unique = []
for cmd in cmds:
key = tuple(cmd)
if key not in seen:
seen.add(key)
unique.append(cmd)
return unique
def main():
cmds = candidate_commands()
found_versions = []
for cmd in cmds:
out = get_output(cmd)
ver = parse_version(out)
if ver:
found_versions.append((cmd[0], ver, out))
if not found_versions:
print('UNKNOWN - Chrome executable/version not found in common locations')
sys.exit(2)
# If multiple installs exist, judge the newest discovered version but print all
newest = max(v for _, v, _ in found_versions)
detail = '; '.join([f'{path} => {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]}' for path, ver, _ in found_versions])
if version_ge(newest, FIXED):
print(f'PATCHED - found {detail}; fixed threshold is {FIXED[0]}.{FIXED[1]}.{FIXED[2]}.{FIXED[3]}')
sys.exit(0)
else:
print(f'VULNERABLE - found {detail}; fixed threshold is {FIXED[0]}.{FIXED[1]}.{FIXED[2]}.{FIXED[3]}')
sys.exit(1)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53, and make sure external XML/XSLT content is getting normal email/web scrutiny. For a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window; the noisgate remediation SLA is ≤ 365 days, but because Chrome already shipped the fix on 2026-06-02, healthy fleets should close this through their normal browser update cycle well before that and document any pinned or stale exceptions.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.