This is a peephole in the browser wall, not a front-door breach
CVE-2026-11096 is an out-of-bounds read in WebRTC in Google Chrome. Per the vendor description, Chrome versions prior to 149.0.7827.53 are affected, and a remote attacker can trigger the bug with a crafted HTML page to read memory they should not see. The disclosure date is 2026-06-04; the fixed desktop build was already appearing in Google's release channels by 2026-05-29.
The vendor's MEDIUM / 6.5 is basically right, and if anything a little generous for enterprise prioritization. Yes, Chrome is everywhere, but the real-world chain still needs user interaction, lands inside a sandboxed browser renderer, and the primitive described is information disclosure, not code execution or sandbox escape. That sharply limits blast radius compared with the Chrome bugs that actually burn incident-response time.
4 steps from start to impact.
Lure the user to attacker HTML
- Target is running Chrome earlier than
149.0.7827.53 - Victim visits attacker-controlled or attacker-influenced content
- WebRTC is available and not disabled by policy
- This is UI:R; no click, no bug
- Browser filtering, URL rewriting, and safe-browsing controls reduce successful delivery
- Many enterprises patch Chrome quickly through auto-update or managed rings
Trigger the WebRTC OOB read
- Bug is reachable in the victim's platform/build
- Attacker can reliably shape input to hit the faulty read
- OOB reads are often noisy and brittle across versions and architectures
- Memory layout variability reduces reliability at scale
- Modern browser hardening limits the value of a raw read primitive
Harvest renderer-process data
- Useful secrets must actually be resident in the affected process memory
- The victim must be concurrently handling valuable web sessions or data
- Chrome's site isolation and process separation reduce what is co-resident
- The CVE text promises only potentially sensitive information, not deterministic secret theft
- Leak value depends heavily on victim browsing state at the moment of exploitation
Monetize leaked session material
- Recovered data must be valid and still usable
- Stolen sessions must not be strongly bound to device or MFA state
- Session binding, short-lived tokens, and re-authentication kill a lot of the value
- Identity monitoring can catch impossible-travel or abnormal session reuse
- This is a weak standalone enterprise attack unless chained with something else
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found. Not listed in CISA KEV, and the vendor material surfaced here does not mention exploitation in the wild. |
|---|---|
| KEV status | Not KEV-listed as of 2026-06-05 review against the CISA KEV catalog. |
| PoC availability | No public PoC located in primary-source review. Chromium issue details appear restricted pending patch adoption, which is normal for Chrome security bugs. |
| EPSS | 0.00032 from the user-supplied intel. That is extremely low and supports treating this as a routine browser patch, not an emergency hunt. |
| CVSS and what it really means | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N scores the bug as a clean remote info leak, but the key limiter is UI:R plus the fact that the stated outcome is confidentiality only. |
| Affected versions | Google states Chrome prior to 149.0.7827.53 is affected. In practice that means the enterprise risk pool is unmanaged laggards, broken auto-update rings, VDI gold images, and test systems. |
| Fixed version | Fixed in Chrome 149.0.7827.53. Google's release material shows 149.0.7827.53/.54 entering desktop stable channels on 2026-05-29, and Chrome for Testing shows 149.0.7827.53 as stable by 2026-06-05. |
| Exposure / scanning reality | This is not an internet-facing service flaw, so Shodan/Censys/GreyNoise-style edge telemetry is mostly irrelevant. Exposure is measured by fleet version coverage, not open ports; the upside for defenders is that managed browser telemetry usually answers that quickly. |
| Disclosure date | 2026-06-04 in the supplied intel and Chrome CNA publication stream. |
| Researcher attribution | Not yet clearly exposed in public primary sources reviewed. Chrome commonly withholds detailed bug metadata until enough users are patched. |
noisgate verdict.
The decisive factor is that this bug is a user-driven browser info leak with impact apparently constrained to renderer-process memory, not a reliable remote takeover primitive. Chrome's ubiquity keeps it out of LOW, but the lack of active exploitation, lack of a public weaponized PoC, and limited technical impact keep it firmly out of HIGH.
Why this verdict
- User interaction drags this down: the attacker still needs a victim to browse to malicious content, which makes this a delivery problem before it becomes a memory-leak problem.
- Renderer-only blast radius matters: the published effect is information disclosure from process memory, not code execution or a sandbox escape, so the practical damage is narrower than the CVSS confidentiality score suggests in isolation.
- No exploitation signal: no KEV listing, no public in-the-wild note, and the supplied EPSS 0.00032 all argue against panic patching.
- But Chrome ubiquity keeps it at MEDIUM: even modest browser bugs deserve attention because nearly every enterprise user runs the target and the exploit surface is hostile web content.
Why not higher?
A HIGH rating would need a stronger amplifier: active exploitation, a public PoC with good reliability, clear cross-origin secret exfiltration at scale, or a second-stage path to code execution or sandbox escape. We do not have that here. This is a single-browser-tab style primitive, not a dependable enterprise intrusion accelerant by itself.
Why not lower?
A LOW rating would understate the combination of massive deployment footprint and remote triggerability through normal browsing. Even without code execution, browser memory disclosures can still expose tokens or sensitive page data, and that is too real to throw into backlog hygiene.
What to do — in priority order.
- Enforce browser auto-update — Make sure Chrome stable rings are actually moving and that broken update channels, pinned versions, VDI images, and kiosk builds are surfaced. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but auto-update validation is the fastest way to collapse exposure without heroic effort.
- Inventory lagging Chrome builds — Pull version telemetry from EDR, MDM, SCCM/Intune, browser cloud management, or package inventory and isolate anything below
149.0.7827.53. There is no mitigation SLA — go straight to the 365-day remediation window, so the job is disciplined cleanup of unmanaged and stranded browsers. - Reduce unneeded WebRTC exposure where feasible — If parts of the fleet do not need browser-based calling, conferencing, or RTC workflows, disable or restrict WebRTC via enterprise policy in those segments. This is a compensating control only; for MEDIUM there is no mitigation SLA — go straight to the 365-day remediation window.
- Watch for identity-side fallout — Because the realistic harm here is stolen session material, tune SaaS and IdP analytics for anomalous session reuse, device changes, and suspicious browser-origin activity after risky browsing. That helps catch the part of the chain that actually matters to the business.
- A network vulnerability scanner will not meaningfully help; this is a client-side browser versioning problem, not an exposed server daemon.
- A perimeter WAF does not solve endpoint browsing to arbitrary internet content, especially when the malicious page is delivered over normal HTTPS.
- MFA alone does not fully neutralize session-token theft if the attacker gets reusable browser session material.
Crowdsourced verification payload.
Run this on the target endpoint or through your endpoint management tooling. Invoke it with python3 chrome_cve_2026_11096_check.py on macOS/Linux or py chrome_cve_2026_11096_check.py on Windows; standard user rights are usually enough, though registry and application path visibility are better with local admin.
#!/usr/bin/env python3
# CVE-2026-11096 Chrome version checker
# 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, capture_output=True, text=True, timeout=10)
out = (p.stdout or '') + '\n' + (p.stderr or '')
return out.strip()
except Exception:
return ''
def find_windows():
candidates = [
os.path.join(os.environ.get('ProgramFiles', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(os.environ.get('ProgramFiles(x86)', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(os.environ.get('LocalAppData', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
]
for path in candidates:
if path and os.path.exists(path):
out = run_cmd(['powershell', '-NoProfile', '-Command', f"(Get-Item '{path}').VersionInfo.ProductVersion"])
ver = parse_version(out)
if ver:
return path, ver
try:
import winreg
keys = [
r'SOFTWARE\Google\Chrome\BLBeacon',
r'SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon',
]
for hive in (winreg.HKEY_CURRENT_USER, winreg.HKEY_LOCAL_MACHINE):
for key in keys:
try:
k = winreg.OpenKey(hive, key)
version, _ = winreg.QueryValueEx(k, 'version')
ver = parse_version(version)
if ver:
return f'{hive}:{key}', ver
except OSError:
pass
except Exception:
pass
return None, None
def find_macos():
candidates = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
]
for path in candidates:
if os.path.exists(path):
out = run_cmd([path, '--version'])
ver = parse_version(out)
if ver:
return path, ver
return None, None
def find_linux():
cmds = ['google-chrome', 'google-chrome-stable', 'chromium-browser', 'chromium']
for cmd in cmds:
out = run_cmd([cmd, '--version'])
ver = parse_version(out)
if ver:
return cmd, ver
return None, None
def main():
system = platform.system().lower()
if 'windows' in system:
source, ver = find_windows()
elif 'darwin' in system:
source, ver = find_macos()
else:
source, ver = find_linux()
if not ver:
print('UNKNOWN - Google Chrome version not found')
sys.exit(2)
if cmp_version(ver, FIXED) < 0:
print(f'VULNERABLE - found {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]} from {source}; fixed is 149.0.7827.53+')
sys.exit(1)
else:
print(f'PATCHED - found {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]} from {source}; fixed is 149.0.7827.53+')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53, and clean up pinned or stranded builds first. For a MEDIUM verdict there is noisgate mitigation SLA — no mitigation SLA — go straight to the 365-day remediation window — and the noisgate remediation SLA is ≤365 days; in practice, because this is Chrome, most teams should fold it into the next managed browser rollout rather than let it sit for quarters.Sources
- Google Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
- Google Chrome Releases homepage
- Chrome for Testing availability - stable 149.0.7827.53
- CIRCL Vulnerability-Lookup search results for Chrome June 2026 CVEs
- CIRCL Vulnerability-Lookup Chrome search
- FIRST EPSS overview
- FIRST EPSS API documentation
- CISA Known Exploited Vulnerabilities Catalog
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.