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
- 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.
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. |
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
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.
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()