This is a peephole in the browser, not a kicked-in front door
CVE-2026-11195 is a Chrome MHTML handling flaw that can leak cross-origin data when a victim is lured to a crafted HTML page and then tricked into performing *specific UI gestures*. Affected builds are Chrome versions earlier than 149.0.7827.53 on Linux and the 149.0.7827.53/54 desktop rollout on Windows/macOS; the public CVE text describes the issue as an inappropriate implementation in MHTML leading to confidentiality impact only.
Google's 6.5 / MEDIUM is defensible in lab terms because the bug crosses origin boundaries, but it overstates enterprise urgency. In the field this is constrained by user interaction, extra gesture requirements, no known exploitation, no KEV listing, no public weaponized PoC, and an impact profile limited to data exposure rather than code execution or sandbox escape.
4 steps from start to impact.
Lure the user to attacker content
- Victim uses Google Chrome below the fixed version
- Attacker can deliver a URL or webpage to the victim
- Victim actually opens the page in Chrome
- This is not internet-reachable server software; every attempt depends on user behavior
- Email gateways, browser filtering, and user training cut down the reachable population
- No public campaign or exploit-kit linkage was found
Trigger the MHTML edge case
- The page reaches the vulnerable MHTML behavior
- Chrome protections do not block the specific sequence
- MHTML is a niche feature path compared with core rendering or JavaScript execution bugs
- Restricted bug details slow copycat weaponization
- Chrome's site isolation and origin protections reduce the chance that a logic bug cleanly exposes useful data
Obtain the required user gestures
- Victim performs the exact required gestures
- Victim does not abandon the page when prompts or unusual behavior appears
- Extra gesture requirements sharply reduce success rates at scale
- Modern enterprises often train users to distrust odd browser prompts and workflows
- Any UX anomaly creates defender and user visibility
Read cross-origin data
- Interesting cross-origin content is present in the victim's browser session
- The leaked data is valuable enough to matter operationally
- Blast radius is limited to what the victim browser can access at that moment
- This is not a persistence, lateral movement, or domain takeover primitive
- Session architecture, short-lived tokens, and app-side controls can reduce useful payoff
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found in the sources reviewed, and Google's advisory does not carry its usual 'aware of exploit in the wild' language |
|---|---|
| KEV status | Not listed in CISA's Known Exploited Vulnerabilities Catalog |
| Proof-of-concept availability | No public PoC or weaponized exploit repository was found; the underlying Chromium issue 503865896 appears restricted |
| EPSS | 0.00014 from the user-supplied intel block; that is effectively noise-floor exploit probability and aligns with the lack of campaign evidence |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — remote and unauthenticated, but user interaction is mandatory and the impact is confidentiality-only |
| Affected versions | Chrome versions earlier than 149.0.7827.53; Google's June 2, 2026 desktop release notes show 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows/Mac |
| Fixed versions | Upgrade to Chrome 149.0.7827.53 or later on Linux, and 149.0.7827.53/54 or later on Windows/macOS per Google's rollout notes |
| Scanning and exposure reality | This is client-side browser software, so Shodan/Censys/FOFA-style internet census data is largely irrelevant. Exposure is determined by endpoint fleet versioning and user browsing behavior, not an open TCP port. |
| Disclosure timeline | CVE published on 2026-06-04; the corresponding Chrome stable desktop update shipped on 2026-06-02 |
| Reporter | Google lists the issue as reported by Google and maps it to Chromium issue 503865896 |
noisgate verdict.
The decisive factor is the exploit chain's dependence on *specific user gestures* after the victim already lands on attacker content. That turns an otherwise broad browser bug into a brittle social-engineering play with low operational reliability and no current evidence of mass exploitation.
Why this verdict
- Downgrade for user dependence: the attacker is unauthenticated and remote, but success still requires the victim to open attacker content in Chrome
- Downgrade again for exploit choreography: the CVE text adds *specific UI gestures*, which is a meaningful reliability penalty beyond ordinary
UI:Rbrowsing - Downgrade for payoff ceiling: the advertised impact is cross-origin data leakage only, with no direct code execution, sandbox escape, persistence, or host takeover
- Downgrade for threat intel: no KEV entry, no public exploitation statement from Google, no public PoC, and an extremely low EPSS all point away from urgent weaponization
- Keep it above IGNORE: Chrome is deployed everywhere, and a same-origin bypass/data leak against live authenticated sessions can still expose tokens, portal data, or internal app content on high-value endpoints
Why not higher?
If this were a passive drive-by or paired with code execution, it would climb fast because Chrome is ubiquitous. But the exploit chain narrows hard on two friction points: the victim must both land on attacker content and perform a specific interaction sequence, and the outcome is data leakage rather than full compromise.
Why not lower?
This is still a browser-origin boundary failure in a product that exists on almost every endpoint. Even a niche, interaction-heavy leak can matter on executive, admin, and finance workstations where browser sessions hold privileged access to sensitive SaaS and internal portals.
What to do — in priority order.
- Force Chrome auto-update compliance — Verify enterprise policy is actually moving endpoints to
149.0.7827.53+on Linux and149.0.7827.53/54+on Windows/macOS. For a LOW verdict there is no mitigation SLA, so treat this as routine hygiene and complete it within thenoisgate remediation SLAbacklog window rather than emergency change control. - Tighten risky browsing paths — Reduce successful lure rate by enforcing Safe Browsing, URL filtering, and attachment detonation for email and chat-delivered links. This helps immediately because the exploit cannot start without the victim opening attacker content.
- Protect high-value users first — Prioritize administrators, finance, executives, and users with privileged SaaS sessions because browser confidentiality bugs pay off most on those endpoints. Even with a LOW severity verdict, targeted-user exposure reduction is the best temporary defense until fleet patching catches up.
- Review browser telemetry retention — Ensure you retain Chrome version inventory and basic browser-security event telemetry long enough to answer 'who was below the fixed build' during the rollout. This does not stop exploitation, but it makes post-event scoping possible.
- EDR alone doesn't solve this, because the vulnerability is a browser logic/data-leak issue rather than a malware dropper or process injection chain
- Perimeter vulnerability scanners won't find exploitability on the network, because Chrome is client-side software without a remotely exposed service to probe
- MFA does not materially reduce the browser-side leak itself; if the victim is already authenticated in-session, stolen rendered data may still be valuable
Crowdsourced verification payload.
Run this on the target endpoint or via your software-inventory agent. Invoke it with python3 check_chrome_cve_2026_11195.py; no admin rights are required if Chrome is installed in standard locations, though wider path access may help on managed images. The script checks common Chrome paths on Windows, macOS, and Linux, reads the installed version, and prints VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env python3
# check_chrome_cve_2026_11195.py
# Purpose: Determine whether the locally installed Google Chrome version is
# vulnerable to CVE-2026-11195 based on fixed version thresholds.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
TARGET_VERSION = (149, 0, 7827, 53)
def parse_version(text):
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
if not m:
return None
return tuple(int(x) for x in m.groups())
def version_to_str(v):
return '.'.join(str(x) for x in v)
def get_output(cmd):
try:
p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
out = (p.stdout or '').strip()
err = (p.stderr or '').strip()
return out if out else err
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'])
where = shutil.which('chrome') or shutil.which('chrome.exe')
if where:
cmds.append([where, '--version'])
elif system == 'darwin':
app = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
if os.path.exists(app):
cmds.append([app, '--version'])
alt = shutil.which('google-chrome')
if alt:
cmds.append([alt, '--version'])
else:
for name in ['google-chrome', 'google-chrome-stable', 'chrome', 'chromium', 'chromium-browser']:
path = shutil.which(name)
if path:
cmds.append([path, '--version'])
for p in ['/opt/google/chrome/chrome', '/usr/bin/google-chrome', '/usr/bin/google-chrome-stable']:
if os.path.exists(p):
cmds.append([p, '--version'])
# de-duplicate
seen = set()
uniq = []
for cmd in cmds:
key = tuple(cmd)
if key not in seen:
seen.add(key)
uniq.append(cmd)
return uniq
def detect_version():
for cmd in candidate_commands():
out = get_output(cmd)
ver = parse_version(out)
if ver:
return ver, ' '.join(cmd)
return None, None
def main():
ver, source = detect_version()
if not ver:
print('UNKNOWN: Google Chrome version not found from common install paths')
sys.exit(2)
if ver < TARGET_VERSION:
print(f'VULNERABLE: detected Chrome {version_to_str(ver)} via {source}; fixed baseline is {version_to_str(TARGET_VERSION)} or later')
sys.exit(1)
else:
print(f'PATCHED: detected Chrome {version_to_str(ver)} via {source}; meets or exceeds fixed baseline {version_to_str(TARGET_VERSION)}')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53, and push the normal browser update ring without waiting for an emergency CAB. Because this reassessment is LOW, there is no noisgate mitigation SLA — treat as backlog hygiene and go straight to the noisgate remediation SLA of <= 365 days; in practice, because browser patching is low-friction, most enterprises should close this in the next regular desktop patch cycle and prioritize high-value user groups first.Sources
- Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
- Chromium issue 503865896
- Vulnerability Lookup / CVE List mirror for CVE-2026-11195
- Canadian Centre for Cyber Security advisory AV26-544
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS overview
- FIRST EPSS API documentation
- Chromium Site Isolation overview
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.