This is a peephole in the browser’s privacy wall, not a front door kicked off its hinges
CVE-2026-11161 is a Chrome client-side information disclosure bug in DataTransfer handling. Affected builds are Chrome versions earlier than 149.0.7827.53 on Linux and earlier than 149.0.7827.53/.54 on Windows and macOS, with the practical fixed floor for enterprises being 149.0.7827.53 or later. The stated impact is cross-origin data leakage through a crafted HTML page, which means the attacker is abusing browser trust boundaries to read data they should not get, not executing code on the endpoint.
Google's MEDIUM 4.3 label is basically fair in the real world. The bug is remotely reachable through web content and Chrome is everywhere, but the chain still needs a user to hit attacker-controlled content, the impact is confidentiality-only and rated low, and there is no evidence in the sources reviewed of KEV listing, public exploitation, or a commodity exploit kit path. For a 10,000-host fleet, this belongs in your normal browser update machinery, not in your emergency patch lane.
4 steps from start to impact.
Host a crafted lure page
DataTransfer behavior. The likely weaponized component is plain browser-native JavaScript rather than a named framework, because the bug lives in web platform handling and does not require a local helper. No public PoC repo was identified in the reviewed sources.- Victim uses Chrome prior to
149.0.7827.53 - Attacker can get the victim to load attacker-controlled web content
- No confirmed public PoC lowers opportunistic abuse
- Email gateways, web filters, Safe Browsing, and user behavior all reduce lure success
Trigger the browser boundary mistake
DataTransfer into exposing cross-origin data. The exact primitive is not public in the reviewed sources, but the effect described by the CVE is a same-origin boundary failure leading to unauthorized data disclosure.- The vulnerable browser code path is reachable from page content
- The victim performs whatever interaction the page requires, consistent with
UI:R
- User interaction is explicitly required by the supplied CVSS vector
- Browser mitigations and changing implementation details often make client-side bug repro brittle across minor builds
Collect leaked cross-origin data
fetch, sendBeacon, or an image request. In practice this is valuable only if the leaked data contains session-bound or application-sensitive content.- Interesting data is present in the browser context at the time of exploitation
- Outbound browser traffic to the attacker is allowed
- Impact is limited to whatever data the primitive can actually expose
- No integrity or availability impact means no direct host takeover from this CVE alone
Use the stolen data for follow-on access
- Leaked data includes reusable tokens, sensitive app data, or internal content
- Target applications do not independently block replay or anomalous session use
- Modern SaaS controls, conditional access, short-lived tokens, and step-up auth can limit reuse
- Blast radius is per-user session context, not a wormable infrastructure event
The supporting signals.
| In-the-wild status | No public evidence found of active exploitation in the reviewed sources as of 2026-06-06. |
|---|---|
| KEV status | Not listed in CISA KEV in the reviewed catalog source; no federal due date applies. Source: CISA KEV catalog |
| Proof-of-concept availability | No public PoC, Metasploit module, or Exploit-DB entry was identified in the reviewed sources. That lowers copy-paste attacker adoption. |
| EPSS | Supplied intel says 0.00012. That is extremely low predicted 30-day exploitation probability; percentile was not confirmed from an authoritative query in the reviewed sources. EPSS reference: FIRST EPSS API docs |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N — remote content can trigger it, but only with user interaction, and the rated impact is confidentiality-low only. |
| Affected versions | Chrome prior to 149.0.7827.53 is affected. Google early stable shipped 149.0.7827.53/.54 for Windows and Mac, and public advisories reference Linux fixed at 149.0.7827.53. Sources: Chrome Releases early stable, Canadian Centre advisory |
| Fixed versions | Patch to 149.0.7827.53 or later. On Windows/macOS, Google early stable references 149.0.7827.53/.54; on Linux advisories call out 149.0.7827.53. |
| Scanning and exposure reality | This is not internet-scannable like a server CVE. GreyNoise, Shodan, Censys, and FOFA are poor fit because the vulnerable asset is the user browser, not a listening service. Your real exposure population is every managed endpoint still pinned below 149.0.7827.53. |
| Disclosure date | Published/disclosed on 2026-06-04 per supplied intel; Chrome-related June 2026 advisory activity is corroborated by Vulnerability-Lookup Chrome entries. |
| Reporting / source pedigree | Chrome-issued CVEs in this batch are assigned by Chrome / [email protected] in aggregated vulnerability records. Public bug details may remain restricted until broad patch adoption. |
noisgate verdict.
The single biggest downward pressure is that this is a user-driven client-side info leak, not a server-side pre-auth takeover. Chrome's ubiquity keeps it from dropping into backlog junk, but the absence of exploitation evidence and the low-impact confidentiality-only outcome keep it out of the urgent lane.
Why this verdict
- Started from the vendor's 4.3 MEDIUM baseline because the stated impact is cross-origin data disclosure, not code execution or sandbox escape.
- User interaction is mandatory: the supplied vector is
UI:R, which means the attacker still needs delivery plus victim engagement with attacker-controlled content. That materially narrows reliable exploitation in enterprise fleets. - This is post-browse, not infrastructure-reachable: there is no exposed daemon, service port, or server workload to scan and mass-weaponize. The attacker only gets a shot when a vulnerable user browser hits their content.
- No active exploitation signal: no KEV listing, no public exploitation evidence, and a supplied EPSS of
0.00012all argue against emergency reprioritization upward. - Blast radius is per-user session context: even if exploited, the expected outcome is data leakage from browser context, not direct host takeover across the fleet.
Why not higher?
There is no evidence in the reviewed sources of active exploitation, no public PoC surfaced, and the impact is not RCE or sandbox escape. The prerequisite chain compounds downward pressure: remote delivery still depends on user interaction and useful data being present in the browser at the time.
Why not lower?
Chrome is one of the most exposed client applications in any enterprise, so even a confidentiality-only browser boundary bug deserves attention. Same-origin and cross-origin leaks can become real account and data exposure when they intersect with live SaaS sessions, internal portals, or privileged admin browsing.
What to do — in priority order.
- Verify Chrome auto-update health — Check for version pinning, disabled updates, stale relaunch debt, and broken update rings. For a MEDIUM verdict there is no mitigation SLA; use this as normal hygiene while you drive to the patch under the 365-day remediation window.
- Prioritize risky user groups — Move admins, finance, help desk, and users with broad SaaS access to the patched build first because browser-session exposure is where this bug pays off for attackers. Again, there is no mitigation SLA for MEDIUM, so do this as part of normal rollout acceleration rather than emergency change control.
- Tighten web egress and filtering — Keep Safe Browsing, secure web gateway policies, DNS filtering, and attachment detonation tuned to reduce the odds that users ever reach malicious lure pages. This lowers exploit reach while patch adoption completes within the remediation window.
- Watch identity and SaaS logs — Because the likely business impact is downstream session or data abuse, monitor impossible travel, token anomalies, new device enrollments, and sensitive data exports from key apps. This is more useful than waiting for endpoint security to name the CVE.
- A WAF does not meaningfully help because the vulnerable component is the client browser, not your server-side application path.
- Network vulnerability scanning will not tell you whether the browser-side exploit path is reachable; at best it inventories version state on endpoints.
- EDR alone is a weak primary control here because browser-internal policy failures often leave little or no host-level malicious artifact.
Crowdsourced verification payload.
Run this on the target endpoint or through your software inventory agent. Invoke it as python3 check_chrome_cve_2026_11161.py on macOS/Linux or py check_chrome_cve_2026_11161.py on Windows; no admin rights are required if Chrome is installed in standard locations. The script checks common Chrome paths and prints VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env python3
# check_chrome_cve_2026_11161.py
# Determine whether installed Google Chrome is below 149.0.7827.53
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
from typing import Optional, Tuple
FIXED = (149, 0, 7827, 53)
def parse_version(text: str) -> Optional[Tuple[int, ...]]:
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
if not m:
return None
return tuple(int(x) for x in m.groups())
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 p.returncode, out.strip()
except Exception:
return 999, ''
def candidate_commands():
system = platform.system().lower()
cmds = []
if system == 'windows':
local = os.environ.get('LOCALAPPDATA', r'C:\Users\Default\AppData\Local')
pf = os.environ.get('PROGRAMFILES', r'C:\Program Files')
pfx86 = os.environ.get('PROGRAMFILES(X86)', r'C:\Program Files (x86)')
candidates = [
os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(pf, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(pfx86, 'Google', 'Chrome', 'Application', 'chrome.exe'),
]
for c in candidates:
cmds.append([c, '--version'])
cmds.append(['reg', 'query', r'HKLM\Software\Google\Chrome\BLBeacon', '/v', 'version'])
cmds.append(['reg', 'query', r'HKCU\Software\Google\Chrome\BLBeacon', '/v', 'version'])
elif system == 'darwin':
candidates = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
]
for c in candidates:
cmds.append([c, '--version'])
which = shutil.which('google-chrome')
if which:
cmds.append([which, '--version'])
else:
bins = [
'google-chrome', 'google-chrome-stable', 'chrome', 'chromium', 'chromium-browser'
]
for b in bins:
which = shutil.which(b)
if which:
cmds.append([which, '--version'])
candidates = [
'/opt/google/chrome/chrome',
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
]
for c in candidates:
cmds.append([c, '--version'])
return cmds
def find_version() -> Optional[Tuple[int, ...]]:
seen = set()
for cmd in candidate_commands():
key = tuple(cmd)
if key in seen:
continue
seen.add(key)
rc, out = run_cmd(cmd)
ver = parse_version(out)
if ver:
return ver
return None
def cmp_ver(a, b):
# Normalize length if needed
maxlen = max(len(a), len(b))
aa = a + (0,) * (maxlen - len(a))
bb = b + (0,) * (maxlen - len(b))
if aa < bb:
return -1
if aa > bb:
return 1
return 0
def main():
ver = find_version()
if not ver:
print('UNKNOWN: Google Chrome version not found in standard locations')
sys.exit(2)
ver_str = '.'.join(str(x) for x in ver)
fixed_str = '.'.join(str(x) for x in FIXED)
if cmp_ver(ver, FIXED) < 0:
print(f'VULNERABLE: installed Chrome version {ver_str} is older than fixed {fixed_str}')
sys.exit(1)
else:
print(f'PATCHED: installed Chrome version {ver_str} is at or above fixed {fixed_str}')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53+ through your normal endpoint rings with extra focus on privileged and high-risk users. This is a MEDIUM call, so there is no noisgate mitigation SLA — go straight to the 365-day remediation window; still, because Chrome is ubiquitous and updates are operationally cheap, you should finish broad rollout well before the noisgate remediation SLA ceiling rather than letting old pinned browsers linger all year.Sources
- Chrome Releases: Early Stable Update for Desktop (149.0.7827.53/.54)
- Chrome Releases homepage
- Canadian Centre for Cyber Security advisory AV26-544
- Vulnerability-Lookup Chrome June 2026 entries
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS API documentation
- Chrome Enterprise auto-update policies
- Chrome Enterprise update management guidance
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.