← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-10909 · CWE-416 · Disclosed 2026-06-04

Use after free in Dawn in Google Chrome prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"A useful sandbox-escape chain component, not a one-bug internet fire drill."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on attacker-controlled web content

The chain starts with a user browsing to a malicious page that can exercise Chrome rendering and likely WebGPU/Dawn code paths. There is no public exploit kit tied to this CVE; the practical weapon here is a custom HTML/JavaScript chain built to reach the vulnerable browser surface, as reflected in Google's advisory and issue tracking.
Conditions required:
  • Victim runs vulnerable Chrome before 149.0.7827.53/54
  • Victim visits attacker-controlled content
  • Relevant browser feature path is reachable from the page
Where this breaks in practice:
  • User interaction is required
  • This CVE is not the initial renderer-compromise bug
  • Some enterprises reduce GPU/WebGPU reachability through policy or hardware constraints
Detection/coverage: Secure web gateway and DNS telemetry can show the lure domain, but they will not identify this CVE specifically. Version scanners can reliably flag vulnerable Chrome builds.
STEP 02

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.
Conditions required:
  • A separate renderer compromise primitive
  • Ability to execute attacker logic inside the renderer
Where this breaks in practice:
  • 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
Detection/coverage: Exploit-stage telemetry is weak, but browser crash spikes, EDR exploit-prevention alerts, and unusual renderer behavior are useful clues.
STEP 03

Trigger the Dawn use-after-free for escape leverage

From the compromised renderer, the attacker drives the vulnerable Dawn object lifecycle into a use-after-free condition and tries to convert that memory corruption into a more powerful primitive. The likely goal is sandbox escape or privilege expansion beyond the renderer, which is why this class of bug is valuable in browser chains even when it is not independently reachable.
Conditions required:
  • Renderer foothold already established
  • Access to the vulnerable Dawn/WebGPU code path
  • Exploit reliability across target OS/browser build
Where this breaks in practice:
  • 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
Detection/coverage: Network tools will miss this. Best coverage is host-side: browser exploit protection, crash telemetry, and EDR memory-corruption detections.
STEP 04

Convert browser escape into endpoint impact

If the exploit chain works, the attacker can move from renderer confinement to broader browser or host impact: credential theft, arbitrary file access, downloader execution, or follow-on malware staging under the user's context. At this point the problem is no longer 'a bad web page' but a compromised workstation.
Conditions required:
  • Successful post-renderer exploitation
  • User context valuable enough for follow-on actions
Where this breaks in practice:
  • EDR can still kill child-process launch or persistence attempts
  • Least-privilege endpoints reduce post-escape blast radius
Detection/coverage: EDR should be expected to catch the follow-on behavior better than the browser exploit itself: suspicious child processes, token access, LOLBIN use, and persistence changes.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo 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 availabilityNo 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.
EPSS0.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 statusNot KEV-listed. Reference catalog: CISA KEV.
CVSS vector readoutVendor 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 versionsAffected 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 versionsFixed 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 realityShodan/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 timelineGoogle 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 creditThe stable bulletin credits whiter@xuanyusec and notes the report date as 2026-04-30.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (7.1/10)

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.

HIGH Affected version and patch build mapping
MEDIUM Assessment that this is primarily a sandbox-escape / post-renderer-compromise chain component
MEDIUM No-public-exploitation / no-public-PoC conclusion from reviewed sources

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. Turn on browser exploit telemetry in EDR — Make sure browser crash telemetry, exploit-prevention events, and suspicious child-process creation from chrome.exe / Google Chrome are 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/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()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, treat this as a browser fast-ring item, not a red-alert one-off: pull an inventory of Chrome desktop builds, force-update any endpoints below 149.0.7827.53/54, and use temporary WebGPU disablement only for lagging or high-risk populations. For a HIGH verdict the noisgate mitigation SLA is within 30 days for compensating controls, and the noisgate remediation SLA is within 180 days for the actual patch — but in practice, because this is Chrome, most enterprises should close it on the next normal browser update cycle, not leave it sitting for months.

Sources

  1. Google Chrome stable desktop bulletin, June 2 2026
  2. Google Chrome early stable desktop bulletin, May 29 2026
  3. Chromium issue 508092644
  4. Chromium security page
  5. Canadian Centre for Cyber Security advisory AV26-544
  6. FIRST EPSS
  7. CISA Known Exploited Vulnerabilities Catalog
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.