This is a peephole in the browser wall, not a door kicked off its hinges
CVE-2026-11067 is an uninitialized-use information disclosure bug in Chrome's Dawn component, affecting Chrome versions before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS. A remote attacker has to get a user onto a crafted web page, then abuse the memory-handling flaw to read data that should not be exposed from the browser process.
Google's MEDIUM 6.5 rating is directionally right, but still a bit generous for enterprise patch triage. The big limiter is that this is user-driven, client-side, and disclosure-only: no code execution, no sandbox escape, no privilege gain, and no evidence of active exploitation or public weaponization. On 10,000 endpoints, this matters because Chrome is everywhere—but it is still mostly a chain-enabler rather than the breach by itself.
4 steps from start to impact.
Lure the user to attacker content
Dawn code path.- Victim runs Chrome prior to
149.0.7827.53 - Victim visits attacker-controlled or attacker-influenced web content
- The vulnerable
Dawnpath is reachable in that browser/environment
- This is UI:R; no click, no bug
- Enterprise web filtering, Safe Browsing, mail protection, and user isolation reduce the reachable population
- Not every browsing session meaningfully reaches WebGPU/Dawn-heavy content
Trigger the uninitialized read in Dawn
Dawn into using uninitialized memory. The result is an information disclosure primitive rather than direct memory corruption for code execution.- Specific vulnerable code path is hit
- Memory state aligns enough to leak useful bytes
- Uninitialized-use leaks are noisier and less deterministic than clean RCE primitives
- Browser hardening and allocator behavior can reduce repeatability and usefulness
Harvest browser-process secrets
- Leaked memory contains sensitive material
- The attacker can parse and operationalize the leaked bytes
- Leak quality is highly situational
- Information disclosure alone may yield nothing actionable on many runs
- Modern browser isolation limits what any single process is holding
Turn the leak into real impact
- Attacker has a follow-on use for leaked data
- A second exploit, stolen session, or high-value browser secret is available
- This CVE does not provide code execution by itself
- Meaningful enterprise impact usually requires a second bug or unusually valuable leaked data
The supporting signals.
| In-the-wild status | No KEV listing and I found no authoritative public evidence of active exploitation as of the June 2026 advisory window. |
|---|---|
| Public PoC availability | No credible public PoC located in the sources reviewed; disclosure details appear intentionally sparse while the fix rolls out. |
| EPSS | 0.00035 from the user-supplied intel block; that is very low, and no authoritative percentile was confirmed in source. |
| KEV status | Not listed in CISA KEV; no date-added or due date applies. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N = remote and unauthenticated, but requires user interaction and yields confidentiality impact only. |
| Affected versions | Chrome for Desktop prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/54 on Windows/macOS, per Google-linked advisories. |
| Fixed versions | Upgrade to 149.0.7827.53 or later on Linux; 149.0.7827.53/54 or later on Windows/macOS. Enterprise-managed Chromium derivatives should track equivalent vendor backports separately. |
| Scanning / exposure reality | Shodan/Censys-style internet census is not meaningful here because this is a client-side browser flaw, not an exposed listening service. Your exposure count is basically your vulnerable Chrome estate. |
| Disclosure date | 2026-06-04 from the supplied intel block; related vendor and government advisories appeared 2026-06-02 to 2026-06-05. |
| Reporter / researcher | Not publicly attributed in the easily accessible vendor-facing sources reviewed. |
noisgate verdict.
The decisive factor is that this bug is post-click and disclosure-only: the attacker needs a user to browse attacker content, and the bug by itself does not hand over execution or privilege. Chrome's ubiquity keeps it relevant, but the absence of KEV/exploitation evidence and the need for a second step keep it out of the high-priority emergency lane.
Why this verdict
- UI required drops urgency: this starts with the user loading attacker-controlled content, which immediately narrows reachable population compared with drive-by server flaws.
- Info disclosure only is a real cap: this CVE leaks memory; it does not grant code execution, sandbox escape, or privilege elevation on its own, so it usually needs chaining.
- Very low threat telemetry pulls it down: supplied EPSS is extremely low, there is no KEV entry, and no solid public weaponization surfaced in reviewed sources.
- Wide footprint keeps it from going lower: Chrome is ubiquitous across enterprise fleets, so even a non-RCE browser bug still deserves cleanup at scale.
Why not higher?
If this were an RCE, sandbox escape, or KEV-listed browser zero-day, the score would jump fast. But this one needs user interaction, depends on hitting a specific browser component, and yields a leak whose practical value is inconsistent unless paired with something else.
Why not lower?
It is still a remote browser flaw in one of the most widely deployed applications in the enterprise, and confidentiality bugs in browsers can expose live session material or support exploit chaining. Dismissing it as mere hygiene would understate the fleet-wide exposure surface.
What to do — in priority order.
- Force browser auto-update compliance — Make sure Chrome relaunch enforcement and version compliance reporting are working across the fleet. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but browsers should still be kept on the normal fast update rail because exposure is endpoint-wide.
- Disable or restrict WebGPU where business permits — If you have high-risk user groups or kiosk/VDI pools that do not need advanced browser GPU features, restricting WebGPU reduces reachable attack surface in the affected component. For MEDIUM, there is no mitigation SLA, so use this selectively where operationally easy rather than as an emergency program.
- Harden risky browsing paths — Apply existing browser isolation, web filtering, Safe Browsing enforcement, and ad/script controls to reduce the odds users ever reach attacker content. This does not replace patching, but it meaningfully cuts exploit delivery opportunities while remediation completes within the 365-day window.
- Prioritize high-value user rings — Patch executives, admins, finance, developers, and any unmanaged or frequently roaming endpoints first because the value of leaked browser memory is highest there. Even without a mitigation SLA, ring-based rollout is the pragmatic way to compress risk on a 10,000-host estate.
- A perimeter scanner will not save you here; this is a client browser bug, so external attack-surface tools cannot tell you who is vulnerable.
- MFA does not block exploitation of the browser bug itself; at best it limits follow-on abuse if leaked memory exposes session artifacts that still need reauthentication.
- A WAF is largely irrelevant because the exploit lives in browser-side content processing, not your inbound web application stack.
Crowdsourced verification payload.
Run this on the target endpoint or through your software inventory agent with a local Python 3 interpreter. Invoke as python3 check_chrome_cve_2026_11067.py; it needs only standard user rights, though Windows registry access is used when available. It reports VULNERABLE, PATCHED, or UNKNOWN based on the installed Chrome version versus 149.0.7827.53.
#!/usr/bin/env python3
# check_chrome_cve_2026_11067.py
# Determine whether local Google Chrome is vulnerable to CVE-2026-11067
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
TARGET = (149, 0, 7827, 53)
def parse_version(text):
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text or '')
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, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=5)
out = (p.stdout or '') + ' ' + (p.stderr or '')
return out.strip()
except Exception:
return ''
def get_windows_version():
try:
import winreg
except Exception:
return None
reg_paths = [
(winreg.HKEY_CURRENT_USER, r'Software\Google\Chrome\BLBeacon'),
(winreg.HKEY_LOCAL_MACHINE, r'SOFTWARE\Google\Chrome\BLBeacon'),
(winreg.HKEY_LOCAL_MACHINE, r'SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon'),
]
for hive, path in reg_paths:
try:
with winreg.OpenKey(hive, path) as key:
value, _ = winreg.QueryValueEx(key, 'version')
v = parse_version(str(value))
if v:
return v
except OSError:
pass
candidates = [
os.path.expandvars(r'%ProgramFiles%\Google\Chrome\Application\chrome.exe'),
os.path.expandvars(r'%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe'),
os.path.expandvars(r'%LocalAppData%\Google\Chrome\Application\chrome.exe'),
]
for exe in candidates:
if exe and os.path.exists(exe):
out = run_cmd([exe, '--version'])
v = parse_version(out)
if v:
return v
return None
def get_macos_version():
candidates = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
]
for exe in candidates:
if os.path.exists(exe):
out = run_cmd([exe, '--version'])
v = parse_version(out)
if v:
return v
return None
def get_linux_version():
commands = [
['google-chrome', '--version'],
['google-chrome-stable', '--version'],
['chromium-browser', '--version'],
['chromium', '--version'],
]
for cmd in commands:
out = run_cmd(cmd)
v = parse_version(out)
if v:
return v
paths = [
'/opt/google/chrome/google-chrome',
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/snap/bin/chromium',
'/usr/bin/chromium-browser',
'/usr/bin/chromium',
]
for exe in paths:
if os.path.exists(exe):
out = run_cmd([exe, '--version'])
v = parse_version(out)
if v:
return v
return None
def main():
system = platform.system().lower()
version = None
if 'windows' in system:
version = get_windows_version()
elif 'darwin' in system:
version = get_macos_version()
elif 'linux' in system:
version = get_linux_version()
else:
print('UNKNOWN - unsupported platform: {}'.format(platform.system()))
sys.exit(2)
if not version:
print('UNKNOWN - could not determine Chrome version')
sys.exit(2)
if cmp_version(version, TARGET) < 0:
print('VULNERABLE - installed Chrome version {} is older than {}'.format('.'.join(map(str, version)), '.'.join(map(str, TARGET))))
sys.exit(1)
else:
print('PATCHED - installed Chrome version {} is at or above {}'.format('.'.join(map(str, version)), '.'.join(map(str, TARGET))))
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- Google Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
- Chrome Releases homepage / 2026 archive context
- Canadian Centre for Cyber Security AV26-544
- GovCERT.HK A26-06-08 Multiple Vulnerabilities in Google Chrome
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS overview
- CVE.org record URL
- Quanteta CVE tracker entry
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.