This is a spare key left inside the car, but only after the thief already got into the garage
CVE-2026-11140 is an out-of-bounds read in Chrome's Chromecast code path that can leak process memory after a malicious page has already achieved renderer-process compromise. The user-supplied description and Chrome's published release context place affected builds at versions before 149.0.7827.53, with the fixing stable release shipping as 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows and macOS on June 2, 2026.
Google's MEDIUM 6.5 baseline is directionally fair in a vacuum, but for enterprise prioritization the decisive fact is that this is not an initial-access bug. The attacker must already have popped the renderer, which means the real-world exploit chain needs another browser flaw first; that prerequisite sharply narrows exposure, turns this into a post-compromise info leak, and keeps it out of the same patch queue as direct RCE, sandbox escape, or KEV-listed Chrome bugs.
4 steps from start to impact.
Land the victim on attacker-controlled HTML
- Victim browses to attacker-controlled content
- Chrome version is older than the June 2, 2026 fixed build
- Relevant
Chromecastcode is present in the target browser build
- Requires user interaction (
UI:R) - Phishing, malvertising, or drive-by delivery still has to beat enterprise filtering and user behavior
- This step only positions the attacker; it does not trigger material impact alone
Compromise the renderer with a separate bug
- Attacker has a working renderer compromise for the victim's build
- Exploit survives modern browser mitigations and site isolation
- Victim reaches the exploit path before browser update
- This is the biggest downward pressure on severity: the bug is post-initial-exploit inside the browser
- Usable renderer exploits are expensive and short-lived
- Exploit developers usually prefer chaining leaks that are more deterministic or already known-good
Trigger the Chromecast out-of-bounds read
Chromecast path and read beyond intended memory bounds. The result is an information disclosure primitive, not code execution and not a sandbox escape on its own.- Renderer process is already under attacker control
- The specific
Chromecastcode path is reachable in that session - Memory layout yields data worth leaking
- Component-specific trigger surface reduces universality
- Out-of-bounds reads are often noisy and less deterministic than a targeted arbitrary read
- Leaked data may be low-value or insufficient for a follow-on stage
Use leaked memory to stabilize or extend the chain
- Leaked memory contains useful secrets or addresses
- Attacker has a second-stage objective such as sandbox escape, credential theft, or persistence
- Chain execution stays stable across target population
- Information disclosure alone rarely closes the objective
- Blast radius is limited to the browsing context unless paired with another flaw
- Enterprise browsers restart often and auto-update aggressively, which shortens chain half-life
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found in the sources reviewed, and not listed in CISA KEV as of this assessment. |
|---|---|
| Proof-of-concept availability | No public GitHub or researcher PoC surfaced in primary-source-adjacent references reviewed. The Chromium issue is referenced as 501659253 but appears restricted. |
| EPSS | 0.00047 from the user-supplied intel block; percentile was not independently verified from a primary EPSS record during this assessment. |
| KEV status | No — absent from the CISA Known Exploited Vulnerabilities Catalog. |
| CVSS vector reality check | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N captures the confidentiality impact, but it understates the real friction because the description itself requires a pre-compromised renderer. |
| Affected versions | Chrome builds before 149.0.7827.53 are affected per the CVE record aggregation; Google shipped fixes in the Chrome 149 stable release on June 2, 2026. |
| Fixed versions | 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/macOS) per Google's stable channel release note. Chromium-based browsers may inherit the bug but ship fixes on their own cadence. |
| Scanning / exposure data | Shodan/Censys-style internet exposure counts are not meaningful here because this is a client-side browser vulnerability, not an externally exposed service listening on a socket. |
| Disclosure timeline | CVE metadata shows publication on 2026-06-04; Google announced the fixed stable build on 2026-06-02. |
| Reporter / discoverer | Public reporting attribution was not exposed in the release note entry for this medium-severity bug. The reference set points to a restricted Chromium issue rather than a named external researcher. |
noisgate verdict.
The single biggest driver is the renderer-compromise prerequisite: an attacker must already be executing inside Chrome's sandbox before this bug becomes useful. That turns CVE-2026-11140 from a frontline browser intrusion risk into a narrow post-compromise leak primitive with limited standalone blast radius.
Why this verdict
- Major downgrade for attacker position: this is not unauthenticated remote code execution from the open web; it requires an attacker who already compromised the renderer process, which implies a prior successful browser exploit stage.
- Population narrowing: while Chrome is everywhere, only the subset of victims who are both unpatched *and* hit by a working renderer exploit chain are realistically exposed, which crushes broad enterprise exploitability.
- Impact is leak-only: the bug discloses memory and can help a chain, but by itself it does not grant integrity impact, persistence, or sandbox escape; no KEV listing and a tiny EPSS further argue against high urgency.
Why not higher?
There is no evidence in the reviewed sources of active exploitation, no public PoC surfaced, and the attacker does not get initial code execution from this flaw alone. The need for a preceding renderer compromise is compounding friction, not a footnote — it is the whole severity story.
Why not lower?
It still lives in a massively deployed browser and can leak high-value process memory once chained, which is useful to real exploit developers. Browser exploit chains are exactly where memory disclosure bugs earn their keep, so this should remain in backlog hygiene rather than being ignored outright.
What to do — in priority order.
- Enforce browser auto-update — Push managed Chrome/Chromium update policy so endpoints converge on the fixed build without waiting for user action. For a LOW verdict there is no SLA here; treat it as backlog hygiene and fold into the next normal endpoint policy cycle.
- Prefer browser isolation for high-risk users — Use remote browser isolation or hardened browsing tiers for admins, finance, and targeted users so renderer exploitation lands in a disposable session instead of the endpoint. For a LOW verdict there is no mitigation SLA; deploy as part of broader control maturity, not as an emergency exception.
- Block unmanaged browsers — Use EDR, MDM, or application control to limit unsupported Chromium forks and portable browsers that may lag Chrome's fix cadence. For a LOW verdict there is no SLA; clean this up in the next software governance sweep.
- A WAF does not meaningfully help; this is a client-side browser issue triggered by attacker-controlled web content after the page is rendered.
- Perimeter network ACLs do not solve a renderer-chain bug in a user browser; if the user can browse out, the trigger can arrive.
- A routine credential reset is not a direct mitigation because the flaw is about in-process memory disclosure, not account takeover by itself.
Crowdsourced verification payload.
Run this on the target endpoint or through your software inventory runner, not from an auditor workstation. Invoke it with python3 chrome_cve_2026_11140_check.py on Windows, macOS, or Linux; standard user rights are usually enough because it only reads executable version metadata and common install paths.
#!/usr/bin/env python3
# CVE-2026-11140 local exposure check
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
TARGET = (149, 0, 7827, 53)
def parse_ver(s):
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', s)
if not m:
return None
return tuple(int(x) for x in m.groups())
def cmp_ver(a, b):
return (a > b) - (a < b)
def run(cmd):
try:
p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
if p.returncode == 0:
return p.stdout.strip() or p.stderr.strip()
except Exception:
return None
return None
def windows_candidates():
paths = []
for base in [os.environ.get('ProgramFiles'), os.environ.get('ProgramFiles(x86)'), os.environ.get('LocalAppData')]:
if not base:
continue
paths.extend([
os.path.join(base, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(base, 'Chromium', 'Application', 'chrome.exe'),
os.path.join(base, 'Microsoft', 'Edge', 'Application', 'msedge.exe'),
])
return [p for p in paths if p and os.path.exists(p)]
def windows_file_version(path):
ps = [
'powershell', '-NoProfile', '-Command',
f"(Get-Item '{path.replace("'", "''")}').VersionInfo.ProductVersion"
]
return run(ps)
def unix_candidates():
names = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'microsoft-edge', 'microsoft-edge-stable']
found = []
for n in names:
p = shutil.which(n)
if p:
found.append(p)
extra = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
'/Applications/Chromium.app/Contents/MacOS/Chromium'
]
for p in extra:
if os.path.exists(p):
found.append(p)
return list(dict.fromkeys(found))
def binary_version(path):
out = run([path, '--version'])
if out:
return out
return None
def assess_versions(version_map):
assessed = []
vulnerable = []
patched = []
for name, verstr in version_map.items():
ver = parse_ver(verstr)
if not ver:
continue
assessed.append((name, verstr, ver))
if cmp_ver(ver, TARGET) < 0:
vulnerable.append((name, verstr))
else:
patched.append((name, verstr))
return assessed, vulnerable, patched
def main():
system = platform.system().lower()
versions = {}
if 'windows' in system:
for path in windows_candidates():
ver = windows_file_version(path)
if ver:
versions[path] = ver
else:
for path in unix_candidates():
ver = binary_version(path)
if ver:
versions[path] = ver
assessed, vulnerable, patched = assess_versions(versions)
if vulnerable:
print('VULNERABLE')
for name, ver in vulnerable:
print(f'{name}: {ver}')
sys.exit(1)
if patched:
print('PATCHED')
for name, ver in patched:
print(f'{name}: {ver}')
sys.exit(0)
print('UNKNOWN')
print('No supported Chrome/Chromium executable found or version could not be parsed.')
sys.exit(2)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
- Chromium issue reference 501659253
- Vulnerability-Lookup entry for CVE-2026-11140
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS API documentation
- Canadian Centre for Cyber Security advisory AV26-544
- SecurityWeek coverage of Chrome 149 security fixes
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.