This is a trapdoor in the browser’s GPU wing, not the front door to the whole building
CVE-2026-11152 is an object-lifecycle bug in Dawn, Chromium’s WebGPU implementation. A crafted web page can hit vulnerable code paths and potentially cross the Chrome sandbox boundary. The affected range is Chrome before 149.0.7827.53; Google’s June 2, 2026 stable rollout shipped 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows and macOS, with Android inheriting the same desktop security fixes in 149.0.7827.59 unless otherwise noted.
The published 9.6/CRITICAL framing overstates what defenders should do with this in a 10,000-host fleet. Yes, sandbox escape from a malicious page is a big deal, but this path still needs user interaction, depends on WebGPU/Dawn reachability and compatible GPU acceleration, has no KEV entry or confirmed in-the-wild exploitation, and lacks a public weaponized PoC. That makes it a real HIGH, not a universal emergency.
4 steps from start to impact.
Land the victim on a crafted page
- Victim browses to attacker-controlled or attacker-influenced content
- Chrome version is below 149.0.7827.53
- JavaScript execution is permitted
- This is UI:R; the user has to load the page
- Email gateways, safe browsing, URL filtering, and browser isolation reduce reachability
- No public exploit kit or broadly reused PoC was found
Reach the WebGPU/Dawn path
navigator.gpu and route work through Dawn. On Chrome, WebGPU availability depends on platform support and GPU acceleration state; Chrome documentation explicitly notes WebGPU is disabled when graphics acceleration is off and may also be blocklisted on unsupported adapters.- WebGPU is available on the endpoint
- Hardware acceleration is enabled or the adapter is otherwise usable
- The GPU/platform combination is not blocklisted
- This narrows real exposure versus 'all Chrome users'
- Some enterprise images disable graphics acceleration
- Unsupported or blocklisted GPU setups break the chain before exploitation starts
Trigger the Dawn lifecycle flaw
- A compatible trigger sequence exists for the victim’s Chrome build and GPU stack
- The exploit is reliable enough for the target platform
- GPU-path reliability is notoriously platform- and driver-sensitive
- Chrome issue details are still restricted, which slows commodity weaponization
- The official Chromium severity note says Medium, suggesting the vendor itself does not see this as a straight universal drive-by host compromise
Capitalize on the sandbox break
- Exploit succeeds beyond mere crash
- Post-escape primitives are usable on the target OS
- A sandbox escape alone is not automatically a full-domain event
- EDR, application control, and privilege boundaries still matter after the break
- Blast radius is endpoint-local unless chained with additional creds or lateral movement
The supporting signals.
| In-the-wild status | No confirmed exploitation found in Google’s release note, and the CVE is not listed in CISA KEV in the reviewed catalog source. |
|---|---|
| PoC availability | No public, trustworthy exploit repo or weaponized PoC was found during this review. The Chromium issue remains the primary reference and detailed bug contents are not publicly useful yet. |
| EPSS | 0.00035 (~0.035%), which is very low and lines up with 'not currently a mass-exploitation favorite.' Percentile was not confirmed from a live FIRST query in the reviewed sources. |
| KEV status | Not KEV-listed. That matters because browser bugs with active abuse usually get pulled into KEV fast once exploitation evidence is solid. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H — severe on paper because it models a remote browser-to-higher-privilege break, but it still includes user interaction and says nothing about feature gating or exploit reliability. |
| Affected versions | Chrome <149.0.7827.53. Desktop stable rollout fixed Linux at 149.0.7827.53 and Windows/macOS at 149.0.7827.53/54. |
| Fixed versions | Upgrade to 149.0.7827.53+ on Linux and 149.0.7827.53/54+ on Windows/macOS. Chrome for Android 149.0.7827.59 carries the same desktop security fixes unless otherwise noted by Google. |
| Exposure population reality | This is a client-side browser flaw, not a service exposure. Shodan/Censys-style internet scanning does not meaningfully measure affected population here; your real exposure is whatever share of the fleet runs vulnerable Chrome with WebGPU reachable. |
| Feature gating | Dawn is Chromium’s WebGPU implementation. WebGPU shipped by default on Chrome 113 for Windows/macOS/ChromeOS-capable devices, but Chrome docs also say it is disabled when graphics acceleration is off and may be blocklisted on some hardware. |
| Disclosure and reporting | Published 2026-06-04. Google’s stable update lists it as a Medium Chromium security severity issue and attributes the report to Google on 2026-04-11. |
noisgate verdict.
The decisive downgrade factor is that this is not a universal unauthenticated network service bug; it is a user-driven browser exploit path that also depends on WebGPU/Dawn being reachable on the endpoint. That still leaves a large enterprise population at risk, but it meaningfully narrows reachable exposure versus a true 9.6-style wormable or one-packet remote compromise.
Why this verdict
- Downgrade from 9.6: the chain starts with user interaction. That immediately removes the 'internet can hit it directly at scale' property that justifies true emergency-critical server bugs.
- Downgrade again: exploitation requires the Dawn/WebGPU path to be available. Chrome documentation shows WebGPU can be disabled by policy, unsupported hardware, blocklists, or disabled graphics acceleration, so the exposed population is smaller than 'every Chrome install.'
- Hold at HIGH, not MEDIUM: if the bug is reachable, the impact is still a sandbox escape from malicious web content, which is exactly the kind of browser boundary failure attackers prize for drive-by chains.
- No upward pressure from threat intel: no KEV, no public exploitation evidence, and a very low EPSS all argue against CRITICAL treatment right now.
- Enterprise blast radius is still broad enough for HIGH: Chrome is everywhere, and web content is constant. Even with feature gating, a browser sandbox escape can touch privileged sessions, SSO cookies, and admin workflows on many endpoints.
Why not higher?
It is not higher because the path is constrained by UI:R and feature/hardware reachability. There is also no current evidence of active exploitation or broad public weaponization, which is the normal trigger for moving browser bugs into patch-immediately territory.
Why not lower?
It is not lower because a browser sandbox escape is a meaningful security-boundary failure, not a cosmetic or tenant-contained bug. On a large enterprise fleet, even a partially reachable drive-by path is operationally important because the browser sits next to identity, SaaS sessions, internal apps, and admin consoles.
What to do — in priority order.
- Force browser updates and relaunch — Push Chrome to
149.0.7827.53+(149.0.7827.53/54+on Windows/macOS) and enforce relaunch so the fixed code is actually loaded. For a HIGH verdict, deploy this under the noisgate mitigation window within 30 days, even if Chrome auto-update is already enabled. - Disable hardware acceleration for high-risk cohorts — For admins, finance, developers with production access, and browser-isolation exceptions, set Chrome policy
HardwareAccelerationModeEnabled=falsewhere business impact is acceptable. This reduces WebGPU/Dawn reachability and should be in place within 30 days for exposed high-value populations. - Route risky browsing through browser isolation — Put unmanaged internet browsing, webmail, ad-heavy content, and newly registered domains behind remote browser isolation or a hardened VDI profile. This cuts off the direct local exploit path and should be prioritized within 30 days for the riskiest user groups.
- Tighten web delivery controls — Use safe browsing, DNS/web filtering, phishing-resistant mail controls, and URL detonation to reduce initial page-load opportunities. These controls do not fix the bug, but they materially reduce the volume of exploit attempts landing on vulnerable endpoints within 30 days.
- Hunt for browser-origin post-exploitation — Add detections for unusual child processes from
chrome.exe/Google Chrome, suspicious file writes after browsing sessions, and GPU-process crash clusters. Stand these detections up within 30 days to catch exploitation attempts before the full fleet is remediated.
- A WAF does not help; the victim is the browser, not your server.
- A network vulnerability scanner will only tell you Chrome version at best; it cannot prove whether the endpoint’s WebGPU/Dawn path is reachable or exploitable.
- MFA does not prevent the initial exploit path. It helps after account theft, not during a browser memory-corruption event.
- Relying on Chrome auto-update alone is not enough in enterprise fleets because stalled relaunches leave the vulnerable binary in memory.
Crowdsourced verification payload.
Run this on the target endpoint or through your EDR/software-management agent. Invoke it as python3 check_cve_2026_11152.py or python3 check_cve_2026_11152.py --path "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"; no admin rights are required unless your tooling restricts access to installed application paths.
#!/usr/bin/env python3
"""
Check local Google Chrome version against CVE-2026-11152 fixed build.
Outputs one of: VULNERABLE / PATCHED / UNKNOWN
Exit codes:
0 = PATCHED
1 = VULNERABLE
2 = UNKNOWN / error
"""
import argparse
import os
import platform
import re
import shutil
import subprocess
import sys
from pathlib import Path
FIXED = (149, 0, 7827, 53)
def parse_version(text: str):
m = re.search(r"(\d+)\.(\d+)\.(\d+)\.(\d+)", text)
if not m:
return None
return tuple(int(x) for x in m.groups())
def cmp_ver(a, b):
return (a > b) - (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 p.returncode, out.strip()
except Exception:
return 99, ""
def candidate_paths(user_path=None):
cands = []
if user_path:
cands.append(user_path)
system = platform.system().lower()
if system == "windows":
local = os.environ.get("LOCALAPPDATA", "")
pf = os.environ.get("PROGRAMFILES", "")
pfx86 = os.environ.get("PROGRAMFILES(X86)", "")
cands += [
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"),
]
elif system == "darwin":
cands += [
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome",
str(Path.home() / "Applications/Google Chrome.app/Contents/MacOS/Google Chrome"),
]
else:
cands += [
shutil.which("google-chrome") or "",
shutil.which("google-chrome-stable") or "",
"/usr/bin/google-chrome",
"/usr/bin/google-chrome-stable",
"/opt/google/chrome/chrome",
]
seen = set()
uniq = []
for c in cands:
if c and c not in seen:
uniq.append(c)
seen.add(c)
return uniq
def get_version_from_executable(path):
if not path or not os.path.exists(path):
return None
rc, out = run_cmd([path, "--version"])
ver = parse_version(out)
if ver:
return ver
return None
def get_version_windows_registry():
rc, out = run_cmd([
"reg",
"query",
r"HKLM\Software\Google\Chrome\BLBeacon",
"/v",
"version",
])
ver = parse_version(out)
if ver:
return ver
rc, out = run_cmd([
"reg",
"query",
r"HKCU\Software\Google\Chrome\BLBeacon",
"/v",
"version",
])
ver = parse_version(out)
return ver
def main():
ap = argparse.ArgumentParser(description="Check if installed Google Chrome is vulnerable to CVE-2026-11152")
ap.add_argument("--path", help="Explicit path to Chrome executable", default=None)
args = ap.parse_args()
ver = None
source = None
if platform.system().lower() == "windows":
ver = get_version_windows_registry()
if ver:
source = "registry"
if not ver:
for cand in candidate_paths(args.path):
ver = get_version_from_executable(cand)
if ver:
source = cand
break
if not ver:
print("UNKNOWN - Google Chrome version not found")
sys.exit(2)
if cmp_ver(ver, FIXED) < 0:
print(f"VULNERABLE - Chrome version {'.'.join(map(str, ver))} detected via {source}; fixed is {'.'.join(map(str, FIXED))}+")
sys.exit(1)
else:
print(f"PATCHED - Chrome version {'.'.join(map(str, ver))} detected via {source}; meets fixed baseline {'.'.join(map(str, FIXED))}+")
sys.exit(0)
if __name__ == "__main__":
main()
If you remember one thing.
149.0.7827.53+ (149.0.7827.53/54+ on Windows/macOS), and apply temporary controls like disabling hardware acceleration/WebGPU for high-risk users or routing them into browser isolation within the noisgate mitigation SLA of 30 days. Then close the loop by getting the entire managed fleet onto the fixed build within the noisgate remediation SLA of 180 days; in practice, you should finish much sooner because this is a browser sandbox-boundary bug and straggler endpoints are where these get burned.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.