This is a peephole drilled through the same-origin wall, not a front door kicked off the hinges
CVE-2026-11176 is a Chrome Media implementation flaw that can let a malicious webpage read data it should not get from another origin. The affected population is broad in install base but narrow in versioning: Chrome desktop builds prior to 149.0.7827.53 on Linux and the June 2026 149.0.7827.53/54 stable rollout on Windows and macOS are in scope; downstream Chromium-based browsers are exposed until they rebase or backport the fix.
Google called this MEDIUM (6.5), and that is basically right. The bug is remote and confidentiality-impacting, but it still depends on *user interaction*, a crafted page, and a browser-only blast radius; there is no public sign here of a clean pre-auth worm path, server-side reachability, or code execution chain that would justify a jump into the urgent buckets.
4 steps from start to impact.
Deliver a crafted page
- Unauthenticated remote attacker
- Victim uses vulnerable Chrome build
- Victim browses to attacker-controlled or attacker-influenced content
UI:Ris real friction; no user, no bug- Email gateway, web filtering, Safe Browsing, ad blocking, and user behavior all suppress reachability
- There is no widely-circulating named exploit kit or public PoC for this CVE as of 2026-06-06
Trigger the Media flaw
- Target page hits the vulnerable Media code path
- Cross-origin target data is reachable in the victim browser context
- Modern Chrome isolation features reduce the number of cross-origin cases that yield useful content
- A lot of enterprise SaaS content is additionally protected by CSP, anti-framing, token binding patterns, or app-layer checks
- Bug details are still partly restricted, which usually slows copycat weaponization
Harvest user-scoped data
- Victim is authenticated to a useful target web app or has accessible cross-origin content worth stealing
- Impact is bounded to what the user can access in-browser
- No integrity or availability gain is described
- EDR will not usually see host compromise because there may be none
Operationalize stolen data
- Stolen data has credential, token, or sensitive-content value
- Attacker can use the data before sessions expire or controls revoke access
- Short-lived tokens, conditional access, and app-layer anomaly detection reduce monetization
- The exploit by itself does not provide code execution or persistence
The supporting signals.
| In-the-wild status | No confirmed active exploitation in the sources reviewed; not listed by CISA KEV as of 2026-06-06. |
|---|---|
| Proof-of-concept availability | No public GitHub/Exploit-DB PoC found in quick checks for CVE-2026-11176; that is an inference from current public search results, not a guarantee none exists privately. |
| EPSS | 0.00014 (~0.014%), which is extremely low and argues against emergency reprioritization on exploit-likelihood grounds alone. |
| KEV status | Not KEV-listed; no CISA due date applies. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N = remotely reachable *if* the victim opens attacker content; confidentiality-only impact, no integrity or availability component. |
| Affected versions | Chrome desktop before 149.0.7827.53; Google/Cyber Centre note the June stable rollout as 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows/macOS. |
| Fixed versions | Patch baseline is 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/macOS). Chromium downstreams need either a rebase to the fixed milestone or an explicit vendor backport. |
| Scanning / exposure data | Shodan/Censys/FOFA are basically the wrong lens here: this is a client-side browser bug, not a bannered server service. Internet-wide scanner counts do not tell you your exposed population; your EDR/MDM browser-version inventory does. |
| Disclosure timeline | Chrome stable fix shipped 2026-06-02; CVE record published 2026-06-04. |
| Reporting researcher / org | Reported by Google on 2026-04-14 in Chromium issue 502371717. |
noisgate verdict.
The decisive downward pressure is the *delivery model*: this bug still requires a victim to render attacker-controlled web content, so it is not an always-on remotely exploitable enterprise service flaw. The second limiter is blast radius: the described impact is cross-origin data leakage in the browser context, not code execution, persistence, or host takeover.
Why this verdict
- Start at Google's 6.5 MEDIUM baseline because the primitive is a real same-origin/confidentiality failure in a massively deployed browser.
- Subtract for
UI:Rand client-side reachability: the attacker is unauthenticated remote, but the prerequisite implies user click/view behavior and content delivery success; that is materially less reliable than exploiting an exposed server on your edge. - Subtract for narrow blast radius: even if exploited, the effect is user-profile/browser-session scoped data leakage, not domain-wide compromise, no host code execution, and no built-in persistence.
- Do not subtract all the way to LOW because Chrome is ubiquitous and cross-origin leaks can expose authenticated SaaS data that matters in real enterprises, especially for privileged web admins and finance/legal users.
Why not higher?
There is no evidence here of active exploitation, KEV status, public weaponization, or an easy chain to RCE. The attacker still needs a victim in the loop, and the stated impact is confidentiality leakage inside the browser, which is serious but not in the same operational class as a pre-auth server RCE or browser sandbox escape.
Why not lower?
Calling this LOW would understate the ubiquity of Chrome and the fact that a same-origin break can expose genuinely sensitive web application data. Even without code execution, a browser-session data leak against the right user can become a real incident.
What to do — in priority order.
- Force browser auto-update compliance — Use GPO/MDM/endpoint management to verify Chrome auto-update is enabled and relaunch suppression is not leaving users stranded on stale versions. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but Chrome is low-friction to update, so use routine compliance reporting rather than emergency change control.
- Quarantine pinned or frozen browser rings — Identify VDI pools, kiosk images, legacy app compatibility groups, and hosts with disabled Omaha/Google Update or pinned milestones. These are the systems that turn a normally self-healing browser issue into long-tail exposure; clear them inside the 365-day remediation window and preferably much sooner as part of normal desktop hygiene.
- Tighten malicious-content delivery controls — Lean on secure web gateway, DNS filtering, Safe Browsing, mail-link protection, and browser isolation for untrusted destinations. These controls do not fix the bug, but they directly attack the highest-friction prerequisite: getting a victim to render attacker HTML in the first place.
- Watch high-value SaaS accounts for odd browser-driven access — Because the likely harm is stolen cross-origin web content, bias monitoring toward IdP and SaaS audit logs for privileged users, executives, finance, HR, and admins. This is not a patch substitute, but it is the right detective control for a confidentiality-only browser issue during the remediation window.
- Server-side WAF tuning does not fix a client-side browser implementation flaw; the bug executes in the victim browser after content is rendered.
- Perimeter vulnerability scanners will not meaningfully measure exposure because Chrome on endpoints is not an internet-facing service you can census from the outside.
- MFA by itself does not prevent browser-session data leakage once the victim is already authenticated to the target web app in that browser context.
Crowdsourced verification payload.
Run this on the target endpoint or through your EDR/remote-exec tool, not from an auditor workstation. Invoke it with python3 check_chrome_cve_2026_11176.py on macOS/Linux or py check_chrome_cve_2026_11176.py on Windows; no admin rights are normally required.
#!/usr/bin/env python3
# check_chrome_cve_2026_11176.py
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
FIXED = (149, 0, 7827, 53)
VERSION_RE = re.compile(r'(\d+)\.(\d+)\.(\d+)\.(\d+)')
def parse_version(text):
m = VERSION_RE.search(text or '')
if not m:
return None
return tuple(int(x) for x in m.groups())
def version_ge(a, b):
return 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 candidate_commands():
system = platform.system().lower()
cmds = []
if system == 'windows':
local = os.environ.get('LOCALAPPDATA', '')
program_files = os.environ.get('ProgramFiles', '')
program_files_x86 = os.environ.get('ProgramFiles(x86)', '')
paths = [
os.path.join(program_files, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(program_files_x86, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),
]
for p in paths:
if p and os.path.exists(p):
cmds.append([p, '--version'])
# Registry fallback via PowerShell if chrome.exe is not in standard paths
cmds.append(['powershell', '-NoProfile', '-Command', "(Get-ItemProperty 'HKLM:\\Software\\Google\\Chrome\\BLBeacon' -ErrorAction SilentlyContinue).version"])
cmds.append(['powershell', '-NoProfile', '-Command', "(Get-ItemProperty 'HKCU:\\Software\\Google\\Chrome\\BLBeacon' -ErrorAction SilentlyContinue).version"])
elif system == 'darwin':
mac_path = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
if os.path.exists(mac_path):
cmds.append([mac_path, '--version'])
for name in ['google-chrome', 'chrome', 'chromium', 'chromium-browser']:
found = shutil.which(name)
if found:
cmds.append([found, '--version'])
else:
for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome']:
found = shutil.which(name)
if found:
cmds.append([found, '--version'])
# Common package-manager fallbacks
cmds.append(['bash', '-lc', "dpkg-query -W -f='${Version}\n' google-chrome-stable 2>/dev/null || true"])
cmds.append(['bash', '-lc', "rpm -q --qf '%{VERSION}-%{RELEASE}\n' google-chrome-stable 2>/dev/null || true"])
return cmds
def main():
seen = []
for cmd in candidate_commands():
out = run_cmd(cmd)
if not out:
continue
ver = parse_version(out)
if ver:
seen.append((cmd[0], ver, out.strip()))
if not seen:
print('UNKNOWN: Could not determine installed Chrome version')
sys.exit(2)
# Choose the highest discovered version if multiple are installed
seen.sort(key=lambda x: x[1], reverse=True)
source, ver, raw = seen[0]
if version_ge(ver, FIXED):
print(f'PATCHED: detected {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]} via {source}')
sys.exit(0)
else:
print(f'VULNERABLE: detected {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]} via {source}; fixed is 149.0.7827.53 or later')
sys.exit(1)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53/54, and clean up pinned or update-disabled populations first. Under the noisgate mitigation SLA, there is no mitigation SLA — go straight to the 365-day remediation window for a MEDIUM finding; under the noisgate remediation SLA, patch the actual vulnerable browser population within 365 days, using normal desktop patching and browser auto-update enforcement rather than emergency outage-level response.Sources
- Google Chrome Releases: Stable Channel Update for Desktop (June 2, 2026)
- Chromium issue 502371717
- Canadian Centre for Cyber Security AV26-544
- SecurityWeek coverage of Chrome 149 release
- PCWorld coverage of Chrome 149 fixes
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS project
- Chrome Releases index
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.