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

Out of bounds read in Dawn in Google Chrome prior to 149

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

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.

"Web-reachable and real, but this is a leak primitive, not a clean one-bug endpoint takeover."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver malicious WebGPU content

The attacker hosts or injects a page that uses JavaScript + WebGPU/WGSL to exercise Dawn. The victim has to browse to the page or render attacker-controlled content inside Chrome. This is a classic browser drive-by starting point, but it is still UI:R rather than silent network-side exploitation.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Network scanners will not see this. Detection comes from browser version inventory, web filtering telemetry, and crash reports tied to chrome, renderer, or GPU-related processes.
STEP 02

Trigger the Dawn out-of-bounds read

The malicious page drives a vulnerable Dawn code path into reading memory outside intended bounds. The weaponized tooling here is just browser-native script and GPU API input; no local foothold is required. The direct outcome is memory disclosure potential, not guaranteed code execution.
Conditions required:
  • The crafted page hits the vulnerable parser/validation/state path in Dawn
  • The target build contains the vulnerable code
Where this breaks in practice:
  • Reliable exploitation often depends on GPU/driver/platform specifics
  • OOB-read bugs are typically less deterministic and less powerful than OOB-write/UAF primitives
Detection/coverage: Most vuln scanners will only flag based on version. Runtime detection is weak unless crash telemetry, browser debugging logs, or sandboxed browser instrumentation is already in place.
STEP 03

Extract useful memory or side effects

If the read is controllable enough, the attacker may recover fragments of process memory such as sensitive page data, pointers, or exploit-stability hints. In practice, this is often useful as a chain helper for bypass work rather than as a complete endpoint-compromise path by itself.
Conditions required:
  • The read returns attacker-observable data or materially changes application behavior
  • The disclosed memory contains something valuable
Where this breaks in practice:
  • 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
Detection/coverage: There is little signature-level coverage. Hunt for abnormal browser crashes, repeated page-triggered renderer resets, or targeted abuse against high-value browsing populations.
STEP 04

Chain with a second primitive for real compromise

To turn this into a serious workstation event, the attacker normally needs another vulnerability such as a renderer escape, same-origin bypass, or stronger memory corruption primitive. That means CVE-2026-11006 should be treated as a dangerous browser bug, but not automatically as a one-CVE endpoint takeover.
Conditions required:
  • Attacker has or finds a complementary exploit primitive
  • Target population is worth burning a multi-bug chain against
Where this breaks in practice:
  • Second-stage exploit requirement sharply narrows real-world opportunistic abuse
  • Modern browser hardening, EDR, and patch cadence raise operational cost for attackers
Detection/coverage: No scanner will prove chaining. Focus on rapid browser patch telemetry and investigate clusters of related Chrome crashes or suspicious browsing incidents.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed active exploitation found in the sources reviewed, and not listed in CISA KEV as of 2026-06-06.
PoC availabilityNo 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.
EPSS0.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 statusNo. The CISA KEV catalog does not show this CVE in the reviewed material.
CVSS / severity baselineNo 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 versionsGoogle 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 versionsTreat 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 realityThis 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 date2026-06-04 via Chrome CNA / CVE publication data in the prompt and correlated Chrome release material.
Reporter / researcherNot publicly attributable from the reviewed material. The linked Chromium issues are access-restricted or do not expose a reporter for this exact CVE.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (5.8/10)

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.

HIGH Affected-version and fixed-version range
MEDIUM Exploit-chain assessment for this exact CVE
MEDIUM Lack of public in-the-wild evidence

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

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

If you remember one thing.

TL;DR
Monday morning, pull a fleet report for Chrome <149.0.7827.53, then move privileged users, admin workstations, and general internet-browsing tiers into your next browser ring first. For a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window under the noisgate remediation SLA; if you cannot update browsers promptly, temporarily disable WebGPU for high-risk cohorts during the current cycle, but the real fix is to get the managed fleet onto 149.0.7827.53+ well before that outer deadline.

Sources

  1. Google Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
  2. NVD - CVE-2026-10927 (Dawn OOB read leading to potential sandbox escape, analogous class)
  3. NVD - CVE-2026-9113 (Chrome OOB read with ADP medium scoring, analogous impact model)
  4. NVD - CVE-2023-1819 (Chrome OOB read with medium severity, analogous impact model)
  5. Chromium issue 41486305 - Dawn/ANGLE undefined behavior leading to OOB reads/writes and type confusion
  6. Chromium issue 501187077 - Dawn WebGPU variant bug with public technical detail / PoC-style research
  7. FIRST EPSS overview and API reference
  8. 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.