This is a peephole drilled through the browser’s same-origin wall, not a front door kicked off its hinges
CVE-2026-11200 is a WebRTC origin-validation / implementation flaw in Google Chrome that can let a remote attacker leak cross-origin data by getting a user to open a crafted HTML page. The affected range is Chrome versions before 149.0.7827.53; Google’s desktop stable release notes show 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows and macOS as the fixed train, with an early stable rollout beginning May 29, 2026 and broader stable promotion on June 2, 2026.
Google’s MEDIUM / 6.5 label is broadly fair, but a bit generous for enterprise patch triage once you do the friction audit. This is not RCE, not a sandbox escape, not wormable, and there is no cited in-the-wild exploitation or KEV listing; the attacker still needs the user to browse attacker-controlled content, and the practical blast radius is usually the victim’s active browser session rather than host takeover.
4 steps from start to impact.
Host the lure page
- Victim runs Chrome older than 149.0.7827.53
- Victim can reach attacker-controlled web content
- No host compromise occurs unless the user actually loads attacker content
- Email gateways, web filters, Safe Browsing, and user behavior all reduce reach
Land the victim on attacker content
- User interaction: open the page or click the link
- Browser protections or policy do not block the destination
- Requires a lure campaign or preexisting control of a site the victim already visits
- Modern enterprise controls can suppress low-reputation destinations
Trigger WebRTC cross-origin leakage
- Specific vulnerable WebRTC code path is reachable in the victim browser build
- Attacker can induce the browser state needed for the leak
- Impact is confidentiality-only in the disclosed scoring
- Bug details are restricted, which slows commodity weaponization
Collect stolen session-context data
- Victim is simultaneously authenticated to sensitive web apps or has interesting browser state
- Leaked data is sufficient to be operationally useful
- Exposure quality depends heavily on what the user is logged into at that moment
- Many sessions are short-lived, scoped, or otherwise less reusable than raw host access
The supporting signals.
| In-the-wild status | No active exploitation evidence found in the primary sources reviewed. Google’s June 2, 2026 release notes do not include the usual 'Google is aware that an exploit exists in the wild' language used on true Chrome zero-days. |
|---|---|
| KEV status | Not listed in CISA KEV based on the KEV catalog reference reviewed; no KEV add date present. |
| Public PoC availability | No widely cited public PoC was found in the vendor advisory, GHSA, or NVD-linked references. The Chromium issue is not publicly detailed from the unauthenticated view, which adds friction. |
| EPSS | 0.00013 (0.013%), roughly 2.1st percentile in Vulnerability-Lookup’s EPSS enrichment dated 2026-06-06; GitHub shows 0.032% / 10th percentile, so both sources place it near the floor. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — network reachable but user-assisted, with confidentiality impact only and no integrity or availability hit. |
| Affected versions | Google Chrome before 149.0.7827.53 across desktop platforms. NVD enrichment models this as versionEndExcluding 149.0.7827.53 for google:chrome. |
| Fixed versions | Linux: 149.0.7827.53; Windows/macOS: 149.0.7827.53/54 in the Chrome 149 stable release train. Chrome also seeded the same fixed build to a small percentage of desktop users on 2026-05-29 via early stable. |
| Scanning / exposure reality | Not meaningfully internet-scannable via Shodan/Censys/FOFA. This is a client-side browser flaw, so external search engines cannot reliably quantify exposure; your true exposure is your managed Chrome fleet and any unmanaged BYOD Chrome population. |
| Disclosure timeline | CVE published by the Chrome CNA on 2026-06-04; Chrome stable containing the fix was already promoted on 2026-06-02. |
| Reporter / provenance | Release notes attribute it to Google and the linked Chromium issue is 504579798, reported 2026-04-20 in the Chrome stable advisory. |
noisgate verdict.
The decisive factor is attacker delivery friction: this bug only becomes dangerous after a user is steered onto attacker-controlled web content, and the disclosed impact is data leakage inside browser scope, not host compromise. With no KEV listing, no vendor-noted in-the-wild exploitation, and EPSS near the floor, this does not earn the same urgency as remotely triggerable server-side flaws or Chrome RCEs.
Why this verdict
- Down from 6.5 because it requires user interaction: the attacker needs the victim to open a crafted page, which implies a lure or a compromised site rather than direct remote reachability into your estate
- Down because it is post-click and client-side: the exposed population is 'users who browse attacker content on vulnerable Chrome,' not every host with port exposure or every server running the product
- Down because the technical impact is confidentiality-only: no integrity or availability loss is scored, and nothing in the primary sources indicates sandbox escape or code execution
- Not lower because Chrome is everywhere: even medium-grade browser bugs matter at enterprise scale when thousands of users carry active sessions to SaaS, admin consoles, and internal apps
- Not lower because cross-origin leakage can still be operationally useful: session-adjacent browser data can enable targeted follow-on abuse against high-value users even without device takeover
Why not higher?
There is no evidence in the reviewed primary sources of active exploitation, KEV inclusion, wormability, or server-side reachability. The attack chain also depends on victim browsing behavior and yields a narrower outcome than the Chrome bugs that justify HIGH or CRITICAL, such as RCE, sandbox escape, or universal security-boundary bypass.
Why not lower?
This is still a remotely delivered browser security-boundary failure in one of the most widely deployed enterprise applications on the planet. If the right user lands on the right page while authenticated to sensitive web apps, the confidentiality impact can be meaningful enough that this should stay out of the backlog-hygiene bucket.
What to do — in priority order.
- Force browser auto-update compliance — Use Chrome Browser Cloud Management, your endpoint platform, or software deployment tooling to drive endpoints to 149.0.7827.53/54 or later. Because this is a MEDIUM finding there is no mitigation SLA; use this as standard risk reduction while you close devices inside the 365-day remediation window.
- Tighten WebRTC IP handling for high-risk groups — Apply the Chrome Enterprise
WebRtcIPHandlingpolicy for admin, finance, and exec populations to reduce what WebRTC can expose and over which interfaces. This is not a full fix, but it is a sensible containment step for users with the most valuable browser sessions while patch adoption completes within the 365-day remediation window. - Restrict media capture defaults where business allows — Set
DefaultMediaStreamSettingto prompt or deny by default for groups that do not need broad WebRTC/media access. That limits related browser abuse surface and is worth doing as a policy hardening measure even though there is no mitigation SLA for a MEDIUM verdict. - Prioritize unmanaged and long-tail endpoints — The real residual risk is not your mainstream managed fleet; it is kiosks, VDI gold images, infrequently used laptops, contractors, and users outside your normal browser update ring. Hunt those exceptions first so they do not remain vulnerable for most of the remediation window.
- A WAF does not meaningfully help because the vulnerable component is the client browser, not your web app perimeter
- An internet exposure scanner will not tell you whether this is fixed because Chrome desktop versions are not reliably externally enumerable
- Generic network segmentation does little for the primary exploit step; the attacker only needs the user to browse a malicious page
- Blocking all WebRTC traffic everywhere is usually too blunt and can break legitimate collaboration apps, while still not substituting for patching
Crowdsourced verification payload.
Run this on the target endpoint or via your EDR/management agent on representative hosts. Invoke it with python3 chrome_cve_2026_11200_check.py on macOS/Linux or py chrome_cve_2026_11200_check.py on Windows; no admin rights are required unless your environment restricts reading application paths/registry.
#!/usr/bin/env python3
# CVE-2026-11200 Chrome version check
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
FIXED = (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 cmp_version(a, b):
return (a > b) - (a < b)
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_windows_version():
candidates = [
[r'reg', 'query', r'HKLM\Software\Google\Chrome\BLBeacon', '/v', 'version'],
[r'reg', 'query', r'HKCU\Software\Google\Chrome\BLBeacon', '/v', 'version'],
[r'wmic', 'datafile', 'where', r'name="C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe"', 'get', 'Version', '/value'],
[r'wmic', 'datafile', 'where', r'name="C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe"', 'get', 'Version', '/value'],
]
for cmd in candidates:
text = run_cmd(cmd)
ver = parse_version(text)
if ver:
return ver, text
return None, ''
def get_macos_version():
candidates = [
['/Applications/Google Chrome.app/Contents/MacOS/Google Chrome', '--version'],
[os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'), '--version'],
['/Applications/Google Chrome.app/Contents/Info.plist'],
]
# Binary --version first
for cmd in candidates[:2]:
if os.path.exists(cmd[0]):
text = run_cmd(cmd)
ver = parse_version(text)
if ver:
return ver, text
# Fallback to defaults read
plist = '/Applications/Google Chrome.app/Contents/Info.plist'
if os.path.exists(plist):
text = run_cmd(['defaults', 'read', '/Applications/Google Chrome.app/Contents/Info', 'CFBundleShortVersionString'])
ver = parse_version(text)
if ver:
return ver, text
return None, ''
def get_linux_version():
candidates = [
['google-chrome', '--version'],
['google-chrome-stable', '--version'],
['/opt/google/chrome/chrome', '--version'],
['/usr/bin/google-chrome', '--version'],
['/usr/bin/google-chrome-stable', '--version'],
]
for cmd in candidates:
prog = cmd[0]
if os.path.isabs(prog) and not os.path.exists(prog):
continue
text = run_cmd(cmd)
ver = parse_version(text)
if ver:
return ver, text
return None, ''
def main():
system = platform.system().lower()
ver = None
raw = ''
if 'windows' in system:
ver, raw = get_windows_version()
elif 'darwin' in system:
ver, raw = get_macos_version()
elif 'linux' in system:
ver, raw = get_linux_version()
else:
print('UNKNOWN - unsupported platform: {}'.format(platform.system()))
sys.exit(2)
if not ver:
print('UNKNOWN - Google Chrome version not found')
sys.exit(2)
if cmp_version(ver, FIXED) < 0:
print('VULNERABLE - detected Chrome version {}.{}.{}.{} < 149.0.7827.53'.format(*ver))
sys.exit(1)
else:
print('PATCHED - detected Chrome version {}.{}.{}.{} >= 149.0.7827.53'.format(*ver))
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
- Chrome Releases - Early Stable Update for Desktop
- GitHub Advisory Database - GHSA-p7mc-g528-g76m
- Vulnerability-Lookup - CVE-2026-11200
- NVD - CVE-2026-11200
- CISA Known Exploited Vulnerabilities Catalog
- Chrome Enterprise Policy - WebRtcIPHandling
- Chrome Enterprise Policy - DefaultMediaStreamSetting
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.