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

Uninitialized Use in Dawn in Google Chrome prior to 149

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

This is a peephole in a skyscraper, not a blown-out wall

CVE-2026-10976 is an *uninitialized use* bug in Chrome's Dawn component, Chromium's WebGPU implementation. In affected Chrome builds prior to 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows and macOS, a malicious site can use crafted HTML to trigger disclosure of potentially sensitive data from browser process memory. The technical impact is *confidentiality only*: memory disclosure, not direct code execution, persistence, or sandbox escape.

Google's HIGH 7.4 vendor rating is understandable from a browser-at-scale perspective, but it lands high for most enterprise patch queues once you do the friction audit. The chain still needs a user to render attacker content, the practical payoff is memory leakage rather than code exec, Chrome's sandbox and Site Isolation limit blast radius, and there is no KEV entry, no known in-the-wild exploitation, and extremely low EPSS. For a 10,000-host fleet, this belongs in the normal browser-update lane, not the incident lane.

"Big exposure, but this is still a user-driven browser info leak without code execution or active exploitation."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a lure page

The attacker needs a victim to load a malicious web page, typically via phishing, malvertising, SEO poisoning, or a compromised legitimate site. The weaponized tool here is just a browser-delivered payload: crafted HTML and JavaScript that drives the vulnerable code path.
Conditions required:
  • Victim uses Google Chrome below 149.0.7827.53
  • Victim browses to attacker-controlled or attacker-influenced content
  • Enterprise controls do not block the destination first
Where this breaks in practice:
  • Requires user interaction; this is not a wormable network service
  • Email gateways, web filters, Safe Browsing, and browser isolation can break the chain before render time
  • Many enterprises auto-update Chrome quickly, shrinking exposure half-life
Detection/coverage: Version-based vulnerability scanners can identify outdated Chrome, but exploit-attempt detection is weak unless you monitor suspicious browser launches, risky destinations, or browser telemetry.
STEP 02

Exercise Dawn via WebGPU

Once the page renders, attacker JavaScript uses WebGPU/Dawn APIs to reach the vulnerable path. The practical exploit kit is a custom JS + WebGPU harness rather than a commodity public exploit framework.
Conditions required:
  • WebGPU/Dawn path is reachable on the victim platform
  • Browser feature availability and GPU stack permit execution
  • Attacker can reliably trigger the uninitialized-use condition
Where this breaks in practice:
  • WebGPU availability is platform-dependent and not uniformly exposed across all enterprise endpoints
  • Some enterprises disable hardware acceleration or constrain risky browser capabilities for sensitive groups
  • No public PoC or turnkey exploit repo is currently visible
Detection/coverage: Most scanners do not validate runtime WebGPU exposure. Browser security telemetry or endpoint monitoring can sometimes flag abnormal GPU API use, but coverage is uneven.
STEP 03

Read leaked process memory

If the bug is triggered successfully, the page may recover unintentionally exposed memory from the vulnerable browser process. The attacker then parses the leaked bytes looking for tokens, page contents, identifiers, or other useful secrets.
Conditions required:
  • Exploit achieves deterministic memory disclosure
  • Useful secrets are present in the disclosed region
  • Browser mitigations do not fully reduce the sensitivity of leaked data
Where this breaks in practice:
  • Information disclosure is noisier and less deterministic than full code execution
  • Chrome Site Isolation and process separation reduce cross-site data exposure in many cases
  • The data obtained may be low-value or incomplete depending on timing and process state
Detection/coverage: There is little signature-based detection for pure in-browser memory disclosure. You are mostly relying on browser version hygiene and upstream web filtering.
STEP 04

Convert leakage into follow-on abuse

The final attacker step is operational, not automatic: any recovered secrets have to be validated and used elsewhere. This is where a browser info leak either fizzles out or becomes an account/session theft problem.
Conditions required:
  • Leaked material contains reusable secrets
  • Those secrets are not already bound to device, origin, or additional controls
  • The attacker has a viable follow-on path
Where this breaks in practice:
  • HTTPOnly cookies, token binding patterns, MFA, and short-lived sessions reduce downstream value
  • A single leak does not guarantee privilege escalation or host takeover
  • Blast radius is usually tied to the victim browser session, not the whole endpoint
Detection/coverage: Downstream detections are stronger than exploit detections: anomalous logins, impossible travel, token misuse, and SaaS session analytics can catch the follow-on abuse.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found in the sources reviewed. Chromium notes that bug details may stay restricted until broad patch adoption, so absence of detail is not evidence of exploitation.
KEV statusNot listed in CISA KEV as of 2026-06-05 review date. That removes the strongest urgency amplifier.
Proof-of-concept availabilityNo public PoC or exploit repo located for CVE-2026-10976 / GHSA-mx4h-4m2f-fwrr. The referenced Chromium issue exists but is not publicly useful without privileged access.
EPSS0.00035 (0.035%), 11th percentile via GitHub/FIRST-linked data. That is very low expected near-term exploitation pressure.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N — remote and low-complexity on paper, but still requires a user to browse attacker content and yields confidentiality impact only.
Affected versionsGoogle states Chrome prior to 149.0.7827.53 is affected; the stable desktop release shipped as 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/Mac).
Fixed versionsUpgrade to 149.0.7827.53 or later on Linux and 149.0.7827.53/54 or later on Windows/macOS. Chromium-based downstream browsers may pick up the fix on their own release lag.
Exposure populationBroad product footprint, narrow exploit surface. Chrome is ubiquitous, but this is a client-side browsing path, not an internet-exposed server endpoint. Shodan/Censys/FOFA-style exposure counting is therefore not applicable.
Disclosure timelineChrome stable update announced 2026-06-02; the advisory data shows the vulnerability published 2026-06-05; the bug was reported by Google on 2026-05-14 in the release notes.
Researcher / reporterReported by Google according to the Chrome stable release notes; no external researcher credit or bounty is shown for this CVE in the public note.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.9/10)

The decisive downgrade factor is that this is a user-driven information disclosure in a browser component, not a service-side unauthenticated takeover path. Chrome's exposure base is massive, but the practical attacker payoff is bounded by needing page render plus successful memory leakage with useful secrets, and there is no exploitation evidence pushing this into the emergency bucket.

HIGH Affected version and patch boundary
MEDIUM Real-world exploitability without public bug details
HIGH Assessment that this is below emergency patch priority absent KEV/active exploitation

Why this verdict

  • Down one full notch for impact reality: vendor CVSS treats confidentiality loss as high, but this is still *info leak only* — no direct code execution, no sandbox escape, no integrity or availability loss.
  • Down for attacker workflow friction: exploitation requires the victim to *load attacker-controlled web content*, which implies phishing, malvertising, SEO poisoning, or site compromise rather than direct network reachability.
  • Down for exploit reliability and reachability: the vulnerable path sits in Dawn/WebGPU, which is materially narrower than 'any HTML parser bug' because runtime feature/platform conditions matter in real fleets.
  • Down for threat intel: not in KEV, no public in-the-wild use found, and EPSS 0.035% / 11th percentile is weak pressure compared with what usually deserves a fleetwide fast lane.
  • Not lower because population matters: Chrome is everywhere, exploitation is remote with no authentication, and session or content leakage from a user browser can still produce meaningful downstream abuse.

Why not higher?

This stops short of HIGH because the attack does not hand over code execution or host compromise by itself. The chain needs user interaction, the exploit output is memory disclosure rather than takeover, and current threat intelligence does not show KEV listing, public weaponization, or active campaigns.

Why not lower?

This is still a remotely triggerable browser bug in one of the most widely deployed client applications in the enterprise. Even confidentiality-only browser flaws can leak tokens, page data, or user secrets, so it is more than backlog trivia.

05 · Compensating Control

What to do — in priority order.

  1. Force browser auto-update compliance — Validate that Chrome stable channels are actually converging to 149.0.7827.53+ through your management plane. For a MEDIUM noisgate verdict there is no mitigation SLA — go straight to the remediation window, but browser drift should still be corrected in the next normal enterprise update cycle.
  2. Disable WebGPU for high-risk user groups — If you have admins, finance, developers with production access, or users in hostile browsing roles, disable or restrict WebGPU/Dawn through enterprise policy as a temporary blast-radius reducer until patched. For MEDIUM, there is no mitigation SLA, so use this selectively where the user risk justifies the operational tradeoff.
  3. Route risky browsing through isolation or filtering — Apply browser isolation, secure web gateway controls, Safe Browsing enforcement, or stricter category filtering to reduce the chance of victims ever rendering attacker pages. This is a sensible compensating control for exposed user populations, but under a MEDIUM rating there is no mitigation SLA driving emergency rollout.
  4. Hunt for stale Chrome installs — Inventory unmanaged laptops, VDI gold images, packaged offline installers, and developer test channels that often miss mainstream browser updates. The operational goal is to eliminate long-tail vulnerable browsers before they sit unpatched inside the 365-day remediation window.
What doesn't work
  • A network IPS signature will not reliably save you here; the payload is just web content and exploit specifics are browser-runtime dependent.
  • Perimeter vulnerability scanning does not meaningfully measure exposure because Chrome is a client application, not a remotely enumerable server service.
  • MFA alone does not prevent exploitation; it only helps if the leak is later converted into account abuse and the stolen material is not enough by itself.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your fleet agent, not from an auditor workstation. Invoke it with python3 check_chrome_cve_2026_10976.py on Windows, macOS, or Linux; it needs only standard user rights because it reads installed application metadata and common install paths. It outputs exactly one of VULNERABLE, PATCHED, or UNKNOWN and exits with 1, 0, or 2 respectively.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_10976.py
# Detects whether installed Google Chrome is below the fixed version for CVE-2026-10976.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import shutil
import subprocess
import sys
from pathlib import Path

FIXED_VERSION = (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, capture_output=True, text=True, timeout=10)
        out = (p.stdout or '') + '\n' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def get_version_windows():
    commands = [
        ["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 commands:
        out = run_cmd(cmd)
        ver = parse_version(out)
        if ver:
            return ver

    candidates = [
        Path(os.environ.get("ProgramFiles", r"C:\Program Files")) / "Google/Chrome/Application/chrome.exe",
        Path(os.environ.get("ProgramFiles(x86)", r"C:\Program Files (x86)")) / "Google/Chrome/Application/chrome.exe",
        Path(os.environ.get("LOCALAPPDATA", "")) / "Google/Chrome/Application/chrome.exe",
    ]
    for exe in candidates:
        if exe.is_file():
            out = run_cmd([str(exe), "--version"])
            ver = parse_version(out)
            if ver:
                return ver
    return None


def get_version_macos():
    candidates = [
        "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome",
        str(Path.home() / "Applications/Google Chrome.app/Contents/MacOS/Google Chrome"),
    ]
    for exe in candidates:
        if os.path.isfile(exe):
            out = run_cmd([exe, "--version"])
            ver = parse_version(out)
            if ver:
                return ver
    return None


def get_version_linux():
    names = ["google-chrome", "google-chrome-stable", "chrome", "chromium", "chromium-browser"]
    for name in names:
        exe = shutil.which(name)
        if exe:
            out = run_cmd([exe, "--version"])
            ver = parse_version(out)
            if ver:
                return ver
    return None


def main():
    system = platform.system().lower()
    if "windows" in system:
        ver = get_version_windows()
    elif "darwin" in system:
        ver = get_version_macos()
    elif "linux" in system:
        ver = get_version_linux()
    else:
        print("UNKNOWN")
        sys.exit(2)

    if not ver:
        print("UNKNOWN")
        sys.exit(2)

    if ver < FIXED_VERSION:
        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 standard browser hygiene with real user exposure, not as a break-glass event. For a MEDIUM verdict there is noisgate mitigation SLA: no mitigation SLA — go straight to the 365-day remediation window, so validate Chrome auto-update health, sweep for unmanaged/out-of-band installs, and patch vulnerable browsers through your normal rings; the noisgate remediation SLA is ≤ 365 days, but because browser updates are low-friction you should realistically absorb this in your next routine Chrome deployment rather than letting it age on the shelf.

Sources

  1. GitHub Advisory Database - GHSA-mx4h-4m2f-fwrr
  2. Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
  3. Chromium Security
  4. Chromium Site Isolation
  5. Chrome for Developers - WebGPU overview
  6. Chrome for Developers - WebGPU troubleshooting
  7. CISA Known Exploited Vulnerabilities Catalog
  8. CWE-457: Use of Uninitialized Variable
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.