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

Bad cast in Dawn in Google Chrome prior to 149

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

This is breaking into a locked office cubicle, not the whole building

CVE-2026-11077 is a memory-safety flaw in Dawn, Chromium's WebGPU implementation, affecting Chrome builds before 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows and macOS. Google's own release notes describe it as an out-of-bounds read in Dawn reported on 2026-04-06; the broader CVSS framing in your intel block treats it like arbitrary code execution inside the browser sandbox via a crafted HTML page.

That vendor-style 8.8/HIGH overstates enterprise patch urgency for defenders. The real friction is stacking: attacker needs a user to hit a malicious page, the primitive is still inside the renderer sandbox, there is no KEV listing, no public exploitation evidence, and EPSS is extremely low; this is a browser exploit-chain component, not a stand-alone workstation takeover.

"Serious bug class, but this one still lands inside Chrome's sandbox and needs user-driven page load."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the user on attacker HTML

The attacker needs a victim to open a malicious webpage or ad frame that exercises the vulnerable Dawn/WebGPU code path. The weaponized tool here is just custom HTML/JavaScript using browser APIs; no public named exploit kit or PoC was found in authoritative sources.
Conditions required:
  • Victim uses Chrome prior to 149.0.7827.53/.54
  • Victim loads attacker-controlled or attacker-influenced web content
  • Relevant WebGPU/Dawn path is reachable on that endpoint
Where this breaks in practice:
  • Requires UI:R; this is not a drive-by daemon exploit against a server
  • Secure web gateway, ad-blocking, URL filtering, and browser isolation can cut reach sharply
  • Some enterprise VDI/headless/unsupported GPU setups will not exercise the same graphics path
Detection/coverage: Version scanners can flag vulnerable Chrome builds, but they cannot prove the Dawn path is actually reachable on every endpoint.
STEP 02

Trigger the Dawn memory bug

Once the page is loaded, attacker JavaScript attempts to trigger the Dawn out-of-bounds read and convert it into a useful primitive. In practice, reliability matters more than the CVSS label: browser memory bugs often need target-specific grooming and can be brittle across GPU, driver, and platform combinations.
Conditions required:
  • The page can invoke the vulnerable API path
  • Heap/layout conditions line up well enough for exploitation
Where this breaks in practice:
  • Google classed this specific bug as Medium in its own release notes
  • An out-of-bounds read is weaker than a clean browser-to-OS takeover primitive
  • Bug details are still restricted, which usually slows commodity weaponization
Detection/coverage: Crash telemetry, renderer terminations, and EDR child-process anomalies may catch failed attempts; preventive scanners generally cannot.
STEP 03

Gain code execution in the sandboxed renderer

Best-case attacker outcome from the available evidence is code execution or a strong memory-disclosure primitive inside Chrome's sandbox. That gives foothold value for credential theft from the browsing session or as a stepping stone into a second bug, but it does not equal host compromise on its own.
Conditions required:
  • Exploit is reliable enough to move beyond crash-only behavior
  • Chrome sandbox remains the only containment boundary being crossed so far
Where this breaks in practice:
  • Renderer sandbox materially limits post-exploitation options
  • Modern EDR often catches suspicious browser child processes, injection attempts, or sandbox-break follow-on behavior
  • A second vulnerability is typically needed for full workstation escape
Detection/coverage: EDR and browser crash reporting have better odds here than network IDS; look for browser-originated anomalous process chains and repeated renderer crashes.
STEP 04

Chain to something bigger

To turn this into true enterprise pain, the attacker usually needs a second-stage sandbox escape, credential phishing overlay, or userland abuse after renderer compromise. That extra prerequisite is the biggest reason this is not a true HIGH for patch triage despite the scary CVSS template.
Conditions required:
  • Attacker has an additional browser or OS escape primitive, or a practical post-sandbox abuse path
Where this breaks in practice:
  • No evidence in sourced material of an active exploit chain using this CVE
  • No KEV entry and extremely low EPSS both argue against immediate large-scale weaponization
Detection/coverage: Detection quality depends on the second-stage technique; this CVE alone is rarely what defenders will directly observe.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo authoritative evidence of active exploitation found in the sourced material as of 2026-06-05; not in CISA KEV.
PoC availabilityNo public PoC or exploit repo was found from authoritative sources. Chromium notes bug details may stay restricted until the fix has broadly shipped.
EPSS0.0008 from your intel block, which is extremely low. I could not confirm the exact percentile from a primary source in hand.
KEV statusNot listed in the CISA Known Exploited Vulnerabilities Catalog.
Vendor vs. product-team severityYour intel block says HIGH 8.8, but Google's release note labels CVE-2026-11077 as Medium and names it an out-of-bounds read in Dawn.
CVSS vector reality checkCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H assumes severe impact once exploited, but the decisive real-world limiter is UI:R + sandboxed renderer impact.
Affected versionsChrome before 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows/macOS.
Fixed versionsDesktop fixed in 149.0.7827.53 (Linux) and 149.0.7827.53/.54 (Windows/Mac). Android 149.0.7827.59 carries the corresponding desktop security fixes per Google's release notes.
Exposure/scanning realityThis is a client-side browser bug, so Shodan/Censys/FOFA-style internet census is largely irrelevant. Exposure is measured by endpoint inventory and browser version drift, not open ports.
Disclosure / reporterPublished in the Chrome stable release on 2026-06-02 and in your intel block as disclosed 2026-06-04; Google attributes the report to Anonymous on 2026-04-06.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.1/10)

The single biggest downward driver is that the available impact stays inside Chrome's sandbox and still requires a user to load hostile content. That makes this a useful exploit-chain component, not an immediate fleet-wide host takeover condition.

HIGH Affected version floor and fixed version identification
MEDIUM Assessment that real-world exploitability is lower than the 8.8 CVSS suggests
LOW Exact exploit reliability across GPU/driver combinations because bug details remain restricted

Why this verdict

  • UI:R cuts the baseline down immediately — this needs a victim to browse to attacker content, so it is not equivalent to an unauthenticated remote service exploit.
  • Sandbox-only impact is the main limiter — even if exploitation succeeds, the public description still lands the attacker inside the browser sandbox, which sharply reduces blast radius versus workstation compromise.
  • Dawn/WebGPU reach is narrower than 'all Chrome traffic' implies — the vulnerable code lives in a graphics stack path whose practical reach varies by platform, GPU support, and enterprise endpoint profile.
  • Threat intel is cold — no KEV, no sourced active exploitation, and EPSS at 0.0008 all push urgency down from the vendor-style HIGH baseline.
  • Google itself called this specific bug Medium — that does not make it harmless, but it is a strong signal that the internal bug quality and exploitability did not justify a top-tier response.

Why not higher?

A HIGH or CRITICAL rating would need at least one major amplifier: active exploitation, a public reliable exploit, a sandbox escape, or no-user-interaction reach. None of those are present in the sourced material. The strongest available descriptions keep the attacker in the renderer sandbox and require page load by a user.

Why not lower?

This is still a browser memory-safety flaw in a massively deployed client application, so ignoring it would be sloppy. Even sandboxed browser code execution or memory disclosure can be chained, and Chrome is one of the few pieces of software your entire workforce touches every day.

05 · Compensating Control

What to do — in priority order.

  1. Verify Chrome auto-update health — Make sure endpoints are actually moving to the fixed build; for a MEDIUM verdict there is no mitigation SLA, so do this in the next normal browser operations cycle and remediate within the 365-day window.
  2. Disable or constrain WebGPU where business allows — If a subset of endpoints does not need advanced browser GPU features, reduce exposure by policy or hardened browser configuration. Treat this as an optional temporary risk reduction during the standard change cycle; there is no mitigation SLA for MEDIUM.
  3. Watch for renderer crash spikes — Repeated Chrome renderer/GPU-process crashes after web browsing are often your only early clue for failed exploitation attempts. Add this to normal telemetry review rather than emergency response unless you see corroborating intel.
  4. Prioritize high-risk user groups first — Even with a MEDIUM verdict, browsers used by executives, developers, finance staff, and high-risk web researchers deserve earlier patch rings because they see more hostile content. Roll those rings first in the normal patch cycle.
What doesn't work
  • Perimeter scanning doesn't help much, because this is not an internet-exposed service vulnerability.
  • MFA does not stop exploitation of a browser memory bug; it only limits some downstream account abuse.
  • Generic email filtering is incomplete protection because any web content source capable of delivering attacker HTML can trigger the browser path.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your endpoint management agent. Invoke it as python3 check_cve_2026_11077.py for auto-discovery, or python3 check_cve_2026_11077.py --path "C:\Program Files\Google\Chrome\Application\chrome.exe"; no admin rights are required, but local file-system access to the browser binary is needed.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_cve_2026_11077.py
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import shutil
import subprocess
import sys

FIX_LINUX = (149, 0, 7827, 53)
FIX_WINMAC = (149, 0, 7827, 54)


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 version_lt(a, b):
    return a < b


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 None, ''


def candidate_paths_from_arg():
    if '--path' in sys.argv:
        i = sys.argv.index('--path')
        if i + 1 < len(sys.argv):
            return [sys.argv[i + 1]]
    return []


def find_candidates():
    system = platform.system().lower()
    cands = []
    cands.extend(candidate_paths_from_arg())

    if system == 'windows':
        envs = [os.environ.get('ProgramFiles'), os.environ.get('ProgramFiles(x86)'), os.environ.get('LocalAppData')]
        rels = [
            r'Google\Chrome\Application\chrome.exe',
            r'Chromium\Application\chrome.exe'
        ]
        for base in envs:
            if base:
                for rel in rels:
                    cands.append(os.path.join(base, rel))
    elif system == 'darwin':
        cands.extend([
            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
            '/Applications/Chromium.app/Contents/MacOS/Chromium'
        ])
    else:
        for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']:
            p = shutil.which(name)
            if p:
                cands.append(p)
        cands.extend([
            '/opt/google/chrome/chrome',
            '/usr/bin/google-chrome',
            '/usr/bin/google-chrome-stable',
            '/usr/bin/chromium',
            '/usr/bin/chromium-browser'
        ])

    seen = set()
    uniq = []
    for c in cands:
        if c and c not in seen:
            seen.add(c)
            uniq.append(c)
    return uniq


def get_version(path):
    if not os.path.exists(path):
        return None, None
    rc, out = run_cmd([path, '--version'])
    ver = parse_version(out)
    if ver:
        return ver, out
    return None, out


def main():
    system = platform.system().lower()
    fix = FIX_WINMAC if system in ('windows', 'darwin') else FIX_LINUX

    candidates = find_candidates()
    found = []

    for path in candidates:
        ver, raw = get_version(path)
        if ver:
            found.append((path, ver, raw))

    if not found:
        print('UNKNOWN - Chrome/Chromium binary not found or version unreadable')
        sys.exit(2)

    # Evaluate the newest discovered version.
    found.sort(key=lambda x: x[1], reverse=True)
    path, ver, raw = found[0]

    # Treat Chromium family versions conservatively as UNKNOWN unless clearly Google Chrome.
    # The CVE is in Chromium code, but patch availability and branding differ by downstream builds.
    is_chrome = 'chrome' in os.path.basename(path).lower() or 'Google Chrome' in raw

    if not is_chrome:
        print(f'UNKNOWN - Found Chromium-family browser at {path} version {".".join(map(str, ver))}; downstream patch status must be verified separately')
        sys.exit(2)

    if version_lt(ver, fix):
        print(f'VULNERABLE - {path} version {".".join(map(str, ver))} is below fixed version {".".join(map(str, fix))}')
        sys.exit(1)
    else:
        print(f'PATCHED - {path} version {".".join(map(str, ver))} meets or exceeds fixed version {".".join(map(str, fix))}')
        sys.exit(0)


if __name__ == '__main__':
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, pull fleet inventory for Chrome versions below 149.0.7827.53 on Linux and below 149.0.7827.54 on Windows/macOS, verify auto-update is functioning, and push this through your normal browser ring rather than emergency change control. There is noisgate mitigation SLA for a MEDIUM here — go straight to the 365-day remediation window — but because browser updates are low-friction, most enterprises should clear it in the next routine browser rollout; under the noisgate remediation SLA, the actual vendor patch still needs to be fully deployed within 365 days.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
  2. Chrome for Testing availability (shows stable 149.0.7827.53)
  3. Chrome Enterprise browser release notes / targeted stable dates
  4. FIRST EPSS API documentation
  5. CISA Known Exploited Vulnerabilities Catalog
  6. Chrome Enterprise policy - EnableUnsafeSwiftShader
  7. Quanteta CVE tracker entry list including CVE-2026-11077 metadata
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.