This is the second lock on the door failing after the burglar is already in the hallway
CVE-2026-10909 is a use-after-free in Dawn, Chrome's WebGPU implementation layer. Google shipped the fix in the June 2, 2026 stable release for Chrome 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows and macOS; versions before those builds are affected. The important detail is in the description: the attacker must have already compromised the renderer process before this bug becomes useful, which makes this a chain component rather than a clean first-stage browser bug.
Google's HIGH / 8.3 label is technically understandable because a working chain can turn a sandboxed renderer foothold into something much worse on a user endpoint. But in enterprise prioritization terms that score runs hot: this CVE is not a one-click standalone takeover, it is a post-renderer-compromise exploit primitive with no public in-the-wild evidence, no KEV entry, and a tiny EPSS signal. I would still keep it in the browser fast ring because Chrome is everywhere and sandbox-escape stages matter, but this is not the same operational priority as an actively exploited first-stage V8 RCE.
4 steps from start to impact.
Land the victim on attacker-controlled web content
- Victim runs vulnerable Chrome before 149.0.7827.53/54
- Victim visits attacker-controlled content
- Relevant browser feature path is reachable from the page
- User interaction is required
- This CVE is not the initial renderer-compromise bug
- Some enterprises reduce GPU/WebGPU reachability through policy or hardware constraints
Gain renderer-process execution with a separate bug
CVE-2026-10909 only matters after the attacker already has code execution or equivalent control inside the renderer process. In other words, the attacker needs a different renderer exploit, malicious extension path, or pre-existing malware foothold before this Dawn bug becomes actionable.- A separate renderer compromise primitive
- Ability to execute attacker logic inside the renderer
- This is the biggest downward pressure on severity: it assumes a prior compromise stage
- Modern browser mitigations, exploit hardening, and content isolation are designed to break this step
Trigger the Dawn use-after-free for escape leverage
- Renderer foothold already established
- Access to the vulnerable Dawn/WebGPU code path
- Exploit reliability across target OS/browser build
- Heap grooming and allocator behavior make UAF exploitation brittle
- Browser hardening such as CFI, sandboxing, and platform mitigations reduce reliability
- Public bug details are still restricted, so reproducibility is not turnkey
Convert browser escape into endpoint impact
- Successful post-renderer exploitation
- User context valuable enough for follow-on actions
- EDR can still kill child-process launch or persistence attempts
- Least-privilege endpoints reduce post-escape blast radius
The supporting signals.
| In-the-wild status | No public exploitation evidence found in the reviewed sources, and not listed in CISA KEV as of 2026-06-05. Google did not add an 'aware of exploit in the wild' note in the June 2, 2026 stable bulletin, which it typically does for known exploitation. |
|---|---|
| Proof-of-concept availability | No public PoC located in the reviewed sources; no GitHub, Metasploit, or vendor-published exploit was found. The Chromium issue exists but details remain restricted: issue 508092644. |
| EPSS | 0.00068 from the user-provided intel, which is 0.068% probability over 30 days. That is a very weak exploitation signal; percentile was not provided in the available source set. |
| KEV status | Not KEV-listed. Reference catalog: CISA KEV. |
| CVSS vector readout | Vendor vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H (8.3 / HIGH). The important practitioner caveat is that the prose description adds an extra real-world prerequisite — renderer compromise first — that CVSS does not model cleanly. |
| Affected versions | Affected Chrome desktop builds are before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS, per Google's June 2, 2026 stable release and Canada's follow-on advisory. |
| Fixed versions | Fixed in 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/macOS). Chrome distributes upstream versioned builds directly; downstream Chromium-based products may absorb the fix on their own schedule and should be validated separately. |
| Exposure/scanning reality | Shodan/Censys/GreyNoise-style exposure data is not meaningful here because this is a client-side desktop browser flaw, not an internet-facing service. Your exposure inventory comes from endpoint software telemetry, browser enterprise reporting, MDM, and EDR — not perimeter scan data. |
| Disclosure timeline | Google pushed the early stable build on 2026-05-29, promoted Chrome 149 stable on 2026-06-02, Canada's Cyber Centre echoed the advisory on 2026-06-03, and the user-provided disclosure date is 2026-06-04. |
| Reporter / research credit | The stable bulletin credits whiter@xuanyusec and notes the report date as 2026-04-30. |
noisgate verdict.
The decisive factor is that this bug requires a renderer compromise first, which makes it a second-stage browser exploit rather than a clean first-stage web bug. I kept it in HIGH because Chrome is ubiquitous and a working Dawn-based escape can turn a contained browser foothold into a real endpoint incident.
Why this verdict
- Major downgrade for prerequisite compromise: the advisory explicitly says the attacker must have already compromised the renderer process. That is a built-in chain requirement and the single biggest friction point.
- Exposure is broad but not directly reachable: Chrome is everywhere, but this CVE is not an unauthenticated one-bug remote endpoint takeover. It is useful only after another exploit stage succeeds.
- No exploitation signal: no KEV listing, no public exploit note from Google, and an EPSS of 0.00068 all argue against emergency treatment.
- Blast radius is still meaningful: if chained successfully, this can help break renderer confinement and materially raise endpoint impact. That keeps it above MEDIUM-to-LOW backlog territory.
Why not higher?
This is not a standalone initial-access browser bug. The attacker first needs renderer compromise, which sharply narrows the reachable population and means another control failure must already have happened before this CVE matters.
Why not lower?
Browsers sit on nearly every endpoint, and sandbox-escape stages are exactly what turns 'contained browser exploit' into 'workstation problem.' Even without public exploitation evidence, a reliable post-renderer UAF in Chrome is too operationally important to dump into annual backlog hygiene.
What to do — in priority order.
- Force browser auto-update compliance — Use your enterprise browser management, MDM, or EDR software inventory to identify Chrome versions below 149.0.7827.53/54 and enforce update policy. For a HIGH verdict, deploy this control within 30 days if patch rollout lags on any cohort.
- Disable WebGPU for high-risk groups — If you have a delayed patch population, use Chrome enterprise policy to disable WebGPU or equivalent risky graphics features on high-risk users such as admins, developers handling untrusted content, and internet-facing staff. This is a sensible blast-radius reducer for this Dawn bug and should be applied within 30 days where patching cannot be immediate.
- Tighten extension governance — Because this CVE only becomes useful after renderer compromise or equivalent browser foothold, reduce alternate browser foothold paths by enforcing extension allowlists and blocking sideloaded/unapproved extensions. Roll that out within 30 days for unmanaged or exception-heavy browser populations.
- Turn on browser exploit telemetry in EDR — Make sure browser crash telemetry, exploit-prevention events, and suspicious child-process creation from
chrome.exe/Google Chromeare feeding your detections. This will not stop the bug itself, but it improves your odds of catching chain execution and should be in place within 30 days.
- WAF rules do not help much here because the vulnerable target is the client browser, not your web application perimeter.
- External attack-surface scanning will not tell you who is exposed; this is an endpoint software-version problem, not an internet-facing service fingerprinting problem.
- MFA is good hygiene but irrelevant to exploitation of a local browser memory-corruption chain.
Crowdsourced verification payload.
Run this on the target endpoint or through your software-distribution/remote-exec tooling. Invoke it with python3 check_chrome_cve_2026_10909.py on macOS/Linux or py check_chrome_cve_2026_10909.py on Windows; no admin rights are required, but local access to the Chrome binary path is needed.
#!/usr/bin/env python3
# check_chrome_cve_2026_10909.py
# Detects vulnerable Google Chrome desktop versions for CVE-2026-10909.
# Outputs exactly one of: VULNERABLE, PATCHED, UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
from shutil import which
FIXED_WINDOWS_MAC = (149, 0, 7827, 53) # 149.0.7827.53/54 are fixed; 53 is minimum fixed build
FIXED_LINUX = (149, 0, 7827, 53)
def parse_version(text):
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, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
out = (p.stdout or '') + '\n' + (p.stderr or '')
return p.returncode, out.strip()
except Exception:
return 999, ''
def candidate_paths():
system = platform.system().lower()
paths = []
if system == 'windows':
envs = [
os.environ.get('ProgramFiles'),
os.environ.get('ProgramFiles(x86)'),
os.environ.get('LocalAppData')
]
suffixes = [
r'Google\\Chrome\\Application\\chrome.exe'
]
for base in envs:
if not base:
continue
for suffix in suffixes:
paths.append(os.path.join(base, suffix))
elif system == 'darwin':
paths.extend([
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome')
])
else:
# Linux
for name in ['google-chrome', 'google-chrome-stable', '/opt/google/chrome/chrome']:
if '/' in name:
paths.append(name)
else:
p = which(name)
if p:
paths.append(p)
# preserve order, remove duplicates
seen = set()
uniq = []
for p in paths:
if p and p not in seen:
seen.add(p)
uniq.append(p)
return uniq
def get_chrome_version():
for path in candidate_paths():
if not os.path.exists(path) and '/' in path:
continue
rc, out = run_cmd([path, '--version'])
ver = parse_version(out)
if ver:
return path, ver, out
return None, None, None
def main():
path, ver, raw = get_chrome_version()
if not ver:
print('UNKNOWN')
sys.exit(2)
system = platform.system().lower()
fixed = FIXED_LINUX if system == 'linux' else FIXED_WINDOWS_MAC
if ver < fixed:
print('VULNERABLE')
sys.exit(1)
else:
print('PATCHED')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.