This is a peephole in Chrome’s GPU plumbing, not a master key to the workstation
CVE-2026-11006 is an out-of-bounds read in Dawn, the Chromium-side implementation used for WebGPU work. In plain English: a malicious page can drive Chrome down a bad code path and make it read memory it should not, which can leak data from the affected process or destabilize it. The affected range is Google Chrome prior to 149.0.7827.53; Google’s release notes show the fix landing with 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows and macOS early-stable builds.
There is no authoritative vendor CVSS baseline for this specific CVE yet, so the right way to score it is by chain reality rather than memory-safety fear alone. A browser bug reachable through web content is never ignorable, but an out-of-bounds read is usually a disclosure primitive or crash aid, not a turnkey one-bug compromise. That pushes this below the usual panic tier for Chrome RCEs and sandbox escapes.
4 steps from start to impact.
Deliver malicious WebGPU content
- Victim uses Chrome below 149.0.7827.53
- Victim visits attacker-controlled or attacker-influenced web content
- WebGPU/Dawn code path is available on the victim platform
- Requires user interaction or content rendering
- Enterprise controls like URL filtering, Safe Browsing, and content isolation can reduce reach
- WebGPU is broadening, but it is still a narrower path than plain HTML/JS engine bugs
chrome, renderer, or GPU-related processes.Trigger the Dawn out-of-bounds read
- The crafted page hits the vulnerable parser/validation/state path in Dawn
- The target build contains the vulnerable code
- Reliable exploitation often depends on GPU/driver/platform specifics
- OOB-read bugs are typically less deterministic and less powerful than OOB-write/UAF primitives
Extract useful memory or side effects
- The read returns attacker-observable data or materially changes application behavior
- The disclosed memory contains something valuable
- Process-memory disclosure is noisy and often low-yield without a second bug
- Chrome sandboxing and process isolation constrain blast radius to the browser process context
Chain with a second primitive for real compromise
- Attacker has or finds a complementary exploit primitive
- Target population is worth burning a multi-bug chain against
- Second-stage exploit requirement sharply narrows real-world opportunistic abuse
- Modern browser hardening, EDR, and patch cadence raise operational cost for attackers
The supporting signals.
| In-the-wild status | No confirmed active exploitation found in the sources reviewed, and not listed in CISA KEV as of 2026-06-06. |
|---|---|
| PoC availability | No public PoC for CVE-2026-11006 found. Public Chromium issues do show Dawn/WebGPU out-of-bounds read/write bug-class research and variant PoC material, which means attacker development cost is not zero but also not science fiction. |
| EPSS | 0.00035 from the prompt intel, which is extremely low and lines up with a bug that looks more like a chain component than mass exploitation bait. |
| KEV status | No. The CISA KEV catalog does not show this CVE in the reviewed material. |
| CVSS / severity baseline | No vendor or NVD CVSS is available for this exact CVE in the reviewed sources. Closest Chrome analogs show a spread from 4.3 MEDIUM for process-memory read scenarios to 6.5 MEDIUM for confidentiality-focused OOB reads, while Chrome's more dangerous Dawn sandbox-escape class lands around 8.3 HIGH. |
| Affected versions | Google Chrome prior to 149.0.7827.53. Early-stable release notes show 149.0.7827.53/.54 for Windows/macOS and 149.0.7827.53 for Linux. |
| Fixed versions | Treat 149.0.7827.53 or later as the floor. In practice, accept 149.0.7827.54 on Windows/macOS where that early-stable build was shipped. |
| Exposure / scanning reality | This is an endpoint browser bug, so Shodan/Censys/FOFA/GreyNoise are poor exposure lenses. Your real exposure source is fleet telemetry: browser version inventory, Chrome enterprise reporting, EDR software inventory, and VDI image baselines. |
| Disclosure date | 2026-06-04 via Chrome CNA / CVE publication data in the prompt and correlated Chrome release material. |
| Reporter / researcher | Not publicly attributable from the reviewed material. The linked Chromium issues are access-restricted or do not expose a reporter for this exact CVE. |
noisgate verdict.
The single biggest downward pressure is that this appears to be an out-of-bounds read with user-driven web reachability, not a direct code-execution or sandbox-escape bug. It is dangerous because Chrome is everywhere, but the impact ceiling of the primitive itself is what keeps it in MEDIUM rather than HIGH.
Why this verdict
- Started from a medium confidentiality baseline: remote browser OOB-read bugs usually map to memory disclosure or crash behavior, not immediate code execution.
- Downward adjustment for primitive strength: this is a read, not a write or use-after-free, so the stand-alone impact is materially narrower.
- Downward adjustment for attacker workflow: exploitation requires victim browsing / content rendering and therefore is UI:R, which cuts wormability and opportunistic reach.
- Downward adjustment for path specificity: the vulnerable code sits in Dawn/WebGPU, a real but narrower execution path than general-purpose DOM/V8 browsing surfaces.
- Upward adjustment for target ubiquity: Chrome is one of the most common enterprise endpoints, so even a medium-strength primitive can matter at fleet scale.
Why not higher?
I am not taking this to HIGH because the current record does not show direct RCE, sandbox escape, or proven active exploitation. To get from this bug to a materially bad enterprise outcome, the attacker likely needs a second primitive or unusually favorable leakage conditions.
Why not lower?
I am not taking this to LOW because the bug is still remote and web-reachable in a massively deployed client. Browser memory-disclosure primitives are routinely useful for exploit chains, especially against privileged users, developers, and admins with valuable browser-resident material.
What to do — in priority order.
- Force browser update telemetry — Use Chrome enterprise reporting, EDR software inventory, or package management to identify endpoints below
149.0.7827.53. For a MEDIUM verdict there is no noisgate mitigation SLA, so use this in the current operations cycle and complete remediation inside the 365-day window; in practice, browsers should ride your next normal update ring. - Disable WebGPU for high-risk cohorts — If patching lags, use Chrome enterprise policy to disable or restrict WebGPU on privileged admins, developers, and externally exposed VDI pools where business impact is acceptable. This is a temporary hardening move, not the fix; for MEDIUM there is no mitigation SLA, so deploy during the current cycle where patch latency exists.
- Prioritize privileged browsing tiers — Patch or harden admin workstations, jump hosts used for general browsing, and executive endpoints first because the value of leaked browser memory is higher there. There is no noisgate mitigation SLA for MEDIUM, but this prioritization should happen immediately in your next browser ring while the full fleet moves toward the patch.
- Watch Chrome crash and reset telemetry — Monitor for abnormal increases in Chrome renderer or GPU-process crashes after visits to suspicious sites. This will not prevent exploitation, but it gives you a way to spot targeting while the fleet is being updated inside the 365-day remediation window.
- A WAF does not help; the vulnerable parser is inside the client browser, not your web edge.
- Internet perimeter scanning does not surface this exposure because browsers are not an internet-listenable service.
- Traditional AV signature matching is weak here because the trigger is attacker-controlled web content using native browser APIs, not a stable malware binary.
Crowdsourced verification payload.
Run this on the target endpoint or through your software-distribution/EDR scripting channel. Invoke with python3 check_chrome_cve_2026_11006.py on macOS/Linux or py check_chrome_cve_2026_11006.py on Windows; standard user rights are usually enough because the script only reads file paths / registry values and prints VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env python3
# check_chrome_cve_2026_11006.py
# Detect Google Chrome version and compare against fixed version for CVE-2026-11006.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
FIXED_VERSION = (149, 0, 7827, 53)
def parse_version(text):
if not text:
return None
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
if not m:
return None
return tuple(int(x) for x in m.groups())
def version_to_str(v):
return '.'.join(str(x) for x in v)
def is_patched(v):
return v >= FIXED_VERSION
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 detect_windows():
candidates = []
# Registry (preferred)
reg_paths = [
["reg", "query", r"HKLM\Software\Google\Chrome\BLBeacon", "/v", "version"],
["reg", "query", r"HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon", "/v", "version"],
["reg", "query", r"HKCU\Software\Google\Chrome\BLBeacon", "/v", "version"],
]
for cmd in reg_paths:
out = run_cmd(cmd)
v = parse_version(out)
if v:
candidates.append(("registry", v))
# Executable paths
exe_paths = [
os.path.join(os.environ.get('ProgramFiles', r'C:\Program Files'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(os.environ.get('ProgramFiles(x86)', r'C:\Program Files (x86)'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(os.environ.get('LOCALAPPDATA', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
]
for path in exe_paths:
if path and os.path.exists(path):
out = run_cmd([path, '--version'])
v = parse_version(out)
if v:
candidates.append((path, v))
return candidates
def detect_macos():
candidates = []
paths = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
]
for path in paths:
if os.path.exists(path):
out = run_cmd([path, '--version'])
v = parse_version(out)
if v:
candidates.append((path, v))
return candidates
def detect_linux():
candidates = []
cmds = [
['google-chrome', '--version'],
['google-chrome-stable', '--version'],
['chromium-browser', '--version'],
['chromium', '--version'],
]
for cmd in cmds:
out = run_cmd(cmd)
v = parse_version(out)
if v:
candidates.append((' '.join(cmd), v))
return candidates
def main():
system = platform.system().lower()
if 'windows' in system:
candidates = detect_windows()
elif 'darwin' in system:
candidates = detect_macos()
else:
candidates = detect_linux()
if not candidates:
print('UNKNOWN: Google Chrome version not found')
sys.exit(2)
# Choose highest discovered version
source, version = sorted(candidates, key=lambda x: x[1], reverse=True)[0]
if is_patched(version):
print(f'PATCHED: detected {version_to_str(version)} via {source}; fixed threshold is {version_to_str(FIXED_VERSION)}')
sys.exit(0)
else:
print(f'VULNERABLE: detected {version_to_str(version)} via {source}; needs {version_to_str(FIXED_VERSION)} or later')
sys.exit(1)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- Google Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
- NVD - CVE-2026-10927 (Dawn OOB read leading to potential sandbox escape, analogous class)
- NVD - CVE-2026-9113 (Chrome OOB read with ADP medium scoring, analogous impact model)
- NVD - CVE-2023-1819 (Chrome OOB read with medium severity, analogous impact model)
- Chromium issue 41486305 - Dawn/ANGLE undefined behavior leading to OOB reads/writes and type confusion
- Chromium issue 501187077 - Dawn WebGPU variant bug with public technical detail / PoC-style research
- FIRST EPSS overview and API reference
- CISA Known Exploited Vulnerabilities Catalog
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.