This is a peephole cut into the browser wall, not a battering ram through the front door
CVE-2026-11106 is a Chrome Media implementation flaw that can let an attacker leak cross-origin data by getting a victim to load a crafted HTML page. On desktop, affected builds are Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS; Google's June 2026 Android release notes say Android builds inherited the same desktop security fixes in 149.0.7827.59.
Google's MEDIUM / 6.5 baseline is basically right, and if anything a little generous for enterprise patch triage. The decisive friction is that this is a client-side, user-interaction, session-dependent confidentiality leak: the attacker needs a victim to browse to hostile content and the victim also needs to have valuable authenticated cross-origin state to steal. That is materially narrower than an internet-facing server flaw or a browser RCE.
3 steps from start to impact.
Deliver a lure page with custom HTML/JS
- Victim uses vulnerable Chrome
- Victim visits attacker-controlled content
- Enterprise controls do not block the lure domain or attachment path
- Requires user interaction; this is not a wormable network service
- Email/web filtering, Safe Browsing, DNS filtering, and user caution all cut reach
- Chrome auto-update shrinks dwell time on managed endpoints
Abuse Media to cross the origin boundary
- Victim browser reaches the vulnerable Media path
- Target cross-origin data is present and accessible in the victim's browsing context
- The bug leaks data only if the victim has something worth stealing in-session
- Impact is confidentiality-only according to the supplied CVSS vector
- Browser hardening, profile isolation, and sign-in separation reduce useful data exposure
Harvest session-bound information
- Victim is logged into a valuable target site
- Exfiltration channel is allowed out of the browser
- No privilege escalation, persistence, or host takeover from this CVE alone
- Stealable data is bounded by the victim's active sessions and browser profile
- SSO re-prompts, device binding, and conditional access can blunt post-theft value
The supporting signals.
| In-the-wild status | No public active exploitation evidence found in the reviewed sources, and not listed in CISA KEV. |
|---|---|
| Proof-of-concept availability | No named public PoC or GitHub exploit repo found in the reviewed sources. Treat this as currently custom-tradecraft territory, not commodity exploit-kit fodder. |
| EPSS | 0.00035 from the user-provided intel; that is extremely low. Percentile was not verified from a primary EPSS response in the sources reviewed. |
| KEV status | Not KEV-listed as of the reviewed CISA KEV catalog source. |
| CVSS / what it really means | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N maps to network-reachable but user-assisted, with confidentiality impact only. In plain English: the victim has to browse somewhere bad, and the prize is leaked data, not device takeover. |
| Affected versions | Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS, per Google's June 2, 2026 desktop stable release materials. |
| Fixed versions | Fixed in 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/macOS). Google's Android June 2, 2026 release notes state Android releases include the same desktop security fixes in 149.0.7827.59 unless otherwise noted. No distro-specific backport bulletin was found in the reviewed sources. |
| Scanning / exposure reality | This is a client-side browser flaw, so Shodan/Censys-style internet exposure counts are the wrong lens. There is no internet-facing service banner to hunt; your exposure is your managed endpoint fleet version drift. |
| Disclosure / reporting | Published 2026-06-04 in the CVE record, highlighted in Google's June 2, 2026 Chrome 149 stable release, and shown as reported by Google on 2026-04-08 in the release archive. |
noisgate verdict.
The single biggest downward pressure is that exploitation requires user interaction and a useful victim browser session; this is a lure-dependent client bug, not an unauthenticated server-side compromise path. Chrome is ubiquitous, but the reachable population for meaningful impact narrows fast once you factor in auto-update, web filtering, and the need for an already-authenticated victim.
Why this verdict
- User interaction required: the attacker cannot hit a listening service; they need to land a lure page in front of a victim.
- Session-bound impact: the payoff depends on the victim already being logged into something worth stealing, which materially narrows real-world blast radius.
- Confidentiality only: no integrity or availability impact in the supplied vector, and no code execution, sandbox escape, or persistence from this CVE alone.
- Not internet-enumerable: Shodan/Censys-style exposure does not amplify this the way it would for an edge appliance or web app; your attack surface is browser fleet hygiene, not exposed ports.
- Low current threat signal: EPSS is extremely low and there is no KEV listing or reviewed public exploitation evidence pushing this upward.
Why not higher?
There is no evidence here of a low-friction, mass-exploitable browser takeover path. The attacker still needs a victim click and a valuable active session, and the resulting impact is data leakage rather than code execution or system compromise.
Why not lower?
Do not dismiss it as LOW just because it is 'only' a browser bug. Chrome is everywhere, and cross-origin leakage against a user with active SaaS sessions can still produce real business impact, especially for finance, HR, admin, and privileged support populations.
What to do — in priority order.
- Enforce managed auto-update — Make Chrome update enforcement non-optional through enterprise policy and confirm relaunch behavior so patched binaries are actually running. For a MEDIUM verdict there is no mitigation SLA, so use this as normal browser hygiene and complete it within your standard patch cycle while still closing drift well before the 365-day remediation ceiling.
- Prioritize high-value browser profiles — Apply version validation first to admin workstations, finance, HR, help desk, executives, and any user groups with broad SaaS access, because the exploit's value is driven by what the victim is already signed into. With no mitigation SLA for MEDIUM, this is targeted risk reduction during normal operations, not an emergency exception process.
- Tighten web and email filtering — Block newly registered domains, suspicious attachment delivery paths, and known phishing infrastructure to reduce the chance that a crafted lure page is ever rendered. This is a sensible hardening layer for this bug class, but for MEDIUM it should ride your normal control-tuning workflow rather than an accelerated emergency window.
- Separate privileged browsing — Use dedicated browser profiles or isolated browsers for privileged/admin tasks and sensitive SaaS workflows so a successful lure in a general browsing session has less to steal. This reduces the exploit's business value because the bug is session-bound rather than host-compromise-driven.
- A WAF on your applications does not fix a browser-side same-origin failure occurring in the victim's endpoint.
- Pure network segmentation does little here because the attack rides normal outbound web browsing from the user device.
- Antivirus signatures alone are weak coverage; the exploit is logic abuse in rendered browser content, not necessarily a dropped malware binary.
Crowdsourced verification payload.
Run this on the target endpoint or through your software-distribution/remote-exec tooling. Invoke it with python3 check_chrome_cve_2026_11106.py on Windows, macOS, or Linux; no admin rights are required if Chrome is installed in standard locations, though elevated rights may help enumerate all-user installs.
#!/usr/bin/env python3
# check_chrome_cve_2026_11106.py
# 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 cmp_version(a, b):
return (a > b) - (a < b)
def candidate_paths():
system = platform.system().lower()
paths = []
if 'windows' in system:
envs = [
os.environ.get('ProgramFiles'),
os.environ.get('ProgramFiles(x86)'),
os.environ.get('LocalAppData')
]
suffixes = [
r'Google\Chrome\Application\chrome.exe',
r'Chromium\Application\chrome.exe'
]
for base in envs:
if base:
for suffix in suffixes:
paths.append(os.path.join(base, suffix))
elif 'darwin' in system:
paths.extend([
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
'/Applications/Chromium.app/Contents/MacOS/Chromium'
])
else:
for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']:
found = shutil.which(name)
if found:
paths.append(found)
paths.extend([
'/opt/google/chrome/chrome',
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/usr/bin/chromium',
'/usr/bin/chromium-browser'
])
# dedupe while preserving order
seen = set()
ordered = []
for p in paths:
if p and p not in seen:
seen.add(p)
ordered.append(p)
return ordered
def get_version(binary):
try:
out = subprocess.check_output([binary, '--version'], stderr=subprocess.STDOUT, timeout=10)
return parse_version(out.decode(errors='ignore'))
except Exception:
return None
def main():
found_any = False
for path in candidate_paths():
if os.path.exists(path) or shutil.which(path):
found_any = True
ver = get_version(path)
if ver is None:
continue
if cmp_version(ver, TARGET_VERSION) < 0:
print(f'VULNERABLE: {path} version {".".join(map(str, ver))} is older than 149.0.7827.53')
sys.exit(1)
else:
print(f'PATCHED: {path} version {".".join(map(str, ver))} is at or above 149.0.7827.53')
sys.exit(0)
if found_any:
print('UNKNOWN: Chrome/Chromium was found, but version could not be determined')
else:
print('UNKNOWN: Chrome/Chromium not found in standard locations')
sys.exit(2)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- Google Chrome Releases - Stable Channel Update for Desktop
- Google Chrome Releases - June 2026 archive
- Chromium issue 500508725
- Chrome for Testing availability
- FIRST EPSS API documentation
- CISA Known Exploited Vulnerabilities Catalog
- Canadian Centre for Cyber Security advisory AV26-544
- GovCERT.HK alert A26-06-08
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.