This is a peephole in the browser wall, not a battering ram through the datacenter door
CVE-2026-11015 is an out-of-bounds read in Chrome's WebGPU path, affecting Chrome versions before 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows and macOS, per Google's June 2026 release train. In plain English: a hostile website can drive the GPU-facing browser code into reading memory it should not read, which can leak process data or help an attacker stabilize a larger exploit chain.
Reality is less dramatic than the generic 'remote attacker' phrasing. This is still a browser bug reachable from the web, so the exposure population is enormous, but the primitive is a read, not a write or direct code-exec. That matters. Without a second bug, modern browser sandboxing, process isolation, and the practical difficulty of turning a WebGPU memory disclosure into durable impact keep this out of urgent-breakglass territory. Google's own release notes tag it Medium, and that matches the field reality.
4 steps from start to impact.
Land the victim on attacker-controlled content
- Victim uses Chrome prior to 149.0.7827.53
- User visits attacker-controlled or attacker-influenced content
- Web content execution is allowed in the browser session
- Requires user interaction or content delivery through an already-compromised site/ad path
- Enterprise web filtering, Safe Browsing, mail/link rewriting, and browser isolation can break the lure stage
Probe for usable WebGPU capability
navigator.gpu and a supported backend are present, then chooses a compatible shader or buffer layout. The weaponized component is the WebGPU JavaScript API plus WGSL shader input. This is a meaningful gate because not every endpoint, GPU stack, or managed browser policy exposes the same WebGPU path.- WebGPU is enabled and supported on the host platform
- The GPU/driver/browser combination reaches the vulnerable code path
- Some enterprises disable or restrict WebGPU with Chrome policy
- Platform and backend variation reduce one-size-fits-all exploit reliability
Trigger the out-of-bounds read in WebGPU
- Specific vulnerable WebGPU code path is reached
- Attacker input survives browser-side validation enough to exercise the faulty path
- Read-only memory bugs are less immediately useful than write/UAF primitives
- Exploit stability often depends on exact browser build, driver behavior, and memory layout
Convert disclosure into something that matters
- Leaked memory contains useful data
- Attacker has a second-stage goal such as session theft, sandbox escape, or exploit chaining
- Chrome process isolation and sandboxing reduce blast radius
- Many successful outcomes require an additional vulnerability or very favorable memory disclosure
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found in the sources reviewed, and the CVE is not listed in CISA KEV. |
|---|---|
| Proof-of-concept availability | No public PoC surfaced in quick GitHub/web review. That does *not* mean exploit development is impossible; it means defenders should not assume commoditized exploitation yet. |
| EPSS | 0.00032 from the prompt intel, which is extremely low and consistent with a browser bug that currently lacks public exploitation signals. |
| KEV status | Not KEV-listed as of the CISA catalog consulted. |
| Vendor severity | Google's 2026 Chrome release notes label CVE-2026-11015: Medium; there is no vendor CVSS score/vector published in the material reviewed. |
| Affected versions | Chrome desktop prior to 149.0.7827.53; Google/Canadian advisory wording for Windows and macOS reflects the rollout as 149.0.7827.53/.54, with Linux at 149.0.7827.53. |
| Fixed version | Treat 149.0.7827.53 or later as the minimum fixed floor for fleet checking; some Windows/macOS channels may report 149.0.7827.54. |
| CVSS vector interpretation | There is no official CVSS vector. *Noisgate inference only:* the shape is closer to a browser-client issue like AV:N/AC:L/PR:N/UI:R with limited direct impact as a standalone read primitive, which is why we keep it in MEDIUM. |
| Exposure / scanning reality | This is a client-side browser issue, so Shodan/Censys/FOFA-style internet census is basically irrelevant. Your exposure answer comes from endpoint inventory / browser version telemetry, not external scanning. |
| Disclosure / researcher | Publicly disclosed 2026-06-04 per prompt intel; Chrome release material shows it was reported by Yuma Takeuchi on 2026-03-29. |
noisgate verdict.
The decisive factor is that this bug gives an attacker a memory-read primitive in a browser feature, not a clean one-bug path to code execution or tenant-wide compromise. Reachability is broad, but the practical impact is sharply reduced by the need for a malicious page, feature/backend compatibility, and usually a second-stage chain to turn the leak into material business damage.
Why this verdict
- Broad reach, but client-side only: any attacker can target users through the web, but this is a browser endpoint issue rather than an internet-facing enterprise service compromise.
- Read primitive, not direct RCE: out-of-bounds *read* is materially less dangerous than write/UAF/type-confusion primitives unless chained with another bug.
- User interaction is required: the attacker needs page render/delivery, which implies phishing, malvertising, or compromised content distribution rather than blind server-side exploitation.
- Feature gate narrows the reachable population: WebGPU support and backend behavior vary by platform, policy, and hardware, which compounds downward pressure on real-world exploit reliability.
- No public KEV / low EPSS / no public PoC found: threat-intel signals do not justify emergency scoring beyond the technical concern.
Why not higher?
This is not scored HIGH or CRITICAL because the available facts point to a standalone information disclosure in a browser subsystem, not a demonstrated one-click RCE or sandbox escape. The chain narrows quickly in practice: the attacker needs victim browsing, a usable WebGPU path, and usually another bug to convert a leak into durable compromise.
Why not lower?
It still deserves MEDIUM because the attack surface is the web browser, one of the most exposed pieces of enterprise software you run. A remotely reachable memory disclosure in Chrome is never backlog trash; even read-only bugs can feed exploit chains, token theft, or mitigation bypass work when aimed at the right targets.
What to do — in priority order.
- Inventory Chrome versions now — Use EDR, MDM, or software inventory to identify endpoints below
149.0.7827.53. For a MEDIUM verdict there is no mitigation SLA; do this in the normal vulnerability review cycle and drive the estate into the remediation window. - Restrict or disable WebGPU where business use is nil — If your managed fleet does not need WebGPU-backed apps, use Chrome enterprise policy to reduce reachable attack surface on higher-risk populations such as privileged admins and finance users. For MEDIUM, there is no mitigation SLA — deploy selectively during ordinary change control, not as an emergency fleet-wide break.
- Prefer browser auto-update with enforcement — This is exactly the kind of client bug that dies fastest when unmanaged version drift dies with it. Enforce update compliance through endpoint management and complete patching within the 365-day remediation window.
- Watch for crash clusters — Repeated Chrome GPU-process or renderer crashes after suspect site visits can be one of the few practical indicators of failed exploitation attempts. Route browser crash telemetry to your detection team and baseline by version and business unit.
- A network perimeter firewall does not meaningfully help; the exploit rides normal outbound web browsing.
- MFA is irrelevant to stopping the memory bug itself; it may reduce downstream account abuse, but it does not block exploit delivery or trigger.
- A generic vulnerability scan of internet-facing assets will miss this exposure completely because the affected product is a client browser, not a server listener.
Crowdsourced verification payload.
Run this on the target endpoint or through your fleet tooling on any host that may have Chrome/Chromium installed. Invoke it with python3 check_chrome_cve_2026_11015.py or python check_chrome_cve_2026_11015.py; no admin rights are required, but the script needs permission to execute local binaries or read common install paths.
#!/usr/bin/env python3
# check_chrome_cve_2026_11015.py
# 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, List
FIXED = (149, 0, 7827, 53)
def parse_version(text: str) -> Optional[Tuple[int, int, int, 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 version_str(v: Tuple[int, int, int, int]) -> str:
return '.'.join(str(x) for x in v)
def run_and_get_version(cmd: List[str]) -> Optional[Tuple[int, int, int, int]]:
try:
p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, text=True, timeout=10)
if p.returncode not in (0, 1):
# Some binaries still print version with non-zero exit.
pass
return parse_version(p.stdout)
except Exception:
return None
def candidate_commands() -> List[List[str]]:
cmds = []
system = platform.system().lower()
if system == 'windows':
local = os.environ.get('LOCALAPPDATA', '')
program_files = os.environ.get('PROGRAMFILES', '')
program_files_x86 = os.environ.get('PROGRAMFILES(X86)', '')
possible = [
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'),
os.path.join(program_files, 'Chromium', 'Application', 'chrome.exe'),
os.path.join(program_files_x86, 'Chromium', 'Application', 'chrome.exe'),
]
for p in possible:
if p and os.path.exists(p):
cmds.append([p, '--version'])
elif system == 'darwin':
possible = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
'/Applications/Chromium.app/Contents/MacOS/Chromium',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
os.path.expanduser('~/Applications/Chromium.app/Contents/MacOS/Chromium'),
]
for p in possible:
if os.path.exists(p):
cmds.append([p, '--version'])
else:
# Linux / other Unix
names = [
'google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome'
]
for name in names:
path = shutil.which(name)
if path:
cmds.append([path, '--version'])
return cmds
def main() -> int:
cmds = candidate_commands()
if not cmds:
print('UNKNOWN: Chrome/Chromium binary not found in common locations')
return 2
found_any = False
vulnerable = []
patched = []
for cmd in cmds:
v = run_and_get_version(cmd)
if not v:
continue
found_any = True
binary = cmd[0]
if v < FIXED:
vulnerable.append((binary, v))
else:
patched.append((binary, v))
if not found_any:
print('UNKNOWN: Unable to parse installed Chrome/Chromium version')
return 2
if vulnerable:
for binary, v in vulnerable:
print(f'VULNERABLE: {binary} -> {version_str(v)} < {version_str(FIXED)}')
if patched:
for binary, v in patched:
print(f'PATCHED (other install): {binary} -> {version_str(v)}')
return 1
for binary, v in patched:
print(f'PATCHED: {binary} -> {version_str(v)} >= {version_str(FIXED)}')
return 0
if __name__ == '__main__':
sys.exit(main())
If you remember one thing.
149.0.7827.53, and fold them into normal endpoint patching rather than incident-mode paging. For a MEDIUM reassessment there is noisgate mitigation SLA — go straight to the 365-day remediation window; if you have slow-moving enclaves or privileged admin workstations with no WebGPU business requirement, reduce surface with policy during routine change control, then complete the actual Chrome update inside the noisgate remediation SLA of 365 days.Sources
- Chrome Releases: Early Stable Update for Desktop (149.0.7827.53/.54)
- Chrome Releases 2026 index showing CVE-2026-11015 as Medium and reported by Yuma Takeuchi
- Canadian Centre for Cyber Security advisory AV26-544
- Chrome ships WebGPU
- Chrome Enterprise previous release notes
- W3C WebGPU Candidate Recommendation Draft
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS User Guide
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.