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

Insufficient validation of untrusted input in Dawn in Google Chrome prior to 149

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

This is a bad lock on a moving car door, not yet proof that the attacker also has the keys to the engine bay

CVE-2026-10983 is an input-validation flaw in Dawn, Chromium's WebGPU implementation, reachable by crafted web content in Google Chrome versions before 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows and macOS. In plain terms: a user lands on hostile HTML, that page drives the browser into the Dawn code path, and the bug may let the attacker corrupt or misuse browser-side processing tied to WebGPU.

The raw label is noisy. Your prompt cites a CRITICAL 9.6 score disclosed on 2026-06-04, but Google's own Chrome stable release on 2026-06-02 lists CVE-2026-10983 as High, not Critical. Real-world severity lands in HIGH because Chrome is everywhere and the trigger is just web content, but this still requires user interaction, likely needs WebGPU/Dawn reachability, and a single browser bug usually needs a second confinement-break to turn into full host compromise.

"Serious browser bug, but not a stop-the-world crisis without exploitation evidence or a second escape bug."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a lure page

The attacker uses phishing, malvertising, SEO poisoning, or a compromised legitimate site to get a target onto attacker-controlled HTML. The weaponized tool here is usually just a browser-delivered exploit page or ad-tech redirector, not a bulky exploit kit.
Conditions required:
  • Target is running Chrome below 149.0.7827.53/.54
  • Target can be induced to visit attacker-controlled or attacker-influenced web content
  • Enterprise filtering does not block the destination first
Where this breaks in practice:
  • Requires user interaction; this is not a wormable network service
  • Modern email gateways, DNS filtering, SWG, and browser isolation can kill the delivery step
  • High-value users may browse from hardened or isolated profiles
Detection/coverage: Web proxy, DNS, and email telemetry usually see the lure domain, but vulnerability scanners do not prove exploitability from the wire.
STEP 02

Reach the Dawn/WebGPU code path

Once the page loads, the attacker must exercise browser features that route execution into Dawn. The practical weapon is a custom JavaScript/WebGPU harness embedded in the page, typically derived from fuzzing or crash triage rather than a public turnkey exploit.
Conditions required:
  • Relevant browser feature path is enabled and reachable on the endpoint
  • GPU/driver/browser combination exposes the vulnerable path
  • The exploit page can execute active script
Where this breaks in practice:
  • Some fleets disable or constrain advanced graphics/browser features by policy
  • Hardware, drivers, headless modes, VDI stacks, and browser flags reduce exploit portability
  • Many exploit attempts die here as renderer or GPU-process crashes instead of reliable code execution
Detection/coverage: Detection is weak at this stage; EDR may only show abnormal browser or GPU-process crashes, and external scanners have no coverage for client-side feature reachability.
STEP 03

Turn input validation failure into useful corruption

The attacker then tries to convert the Dawn flaw into memory corruption or logic misuse that gives control inside a browser-associated process. The offensive tooling is usually a fuzzer-derived primitive plus per-version exploit adjustments for allocator layout, timing, and process model.
Conditions required:
  • The bug is exploitable beyond simple crash behavior
  • Exploit is tuned to the target platform and build
  • Browser mitigations do not stop the primitive outright
Where this breaks in practice:
  • Chrome's sandboxing, CFG, ASLR, partition alloc, and other hardening raise the bar
  • A lot of browser bug weaponization remains brittle across OS, GPU, and driver variants
  • Public sources reviewed do not show a working PoC or in-the-wild exploit for this CVE
Detection/coverage: Expect low signature coverage. EDR can sometimes catch repeated browser crashes, anomalous child processes, or memory-protection alerts, but commodity VM scanners will miss the exploitation step entirely.
STEP 04

Escape browser confinement or monetize in-session access

To get from 'browser process foothold' to 'real enterprise incident,' the attacker normally needs either a second sandbox/privilege boundary bug or a lower-ambition objective like session theft and same-user data access. The weaponized chain here is whatever post-browser primitive the operator already has: token theft, infostealer behavior, or a separate sandbox escape.
Conditions required:
  • Attacker can either break containment or achieve their objective without full host escape
  • Endpoint defenses do not interrupt suspicious follow-on behavior
  • Valuable credentials or sessions are present in the user's context
Where this breaks in practice:
  • A single Dawn issue does not automatically equal SYSTEM/root compromise
  • MFA, EDR, browser process isolation, and credential protections shrink post-exploitation value
  • Without a second bug, blast radius is often constrained to the browser/user context
Detection/coverage: This is where defenders usually win: EDR, identity telemetry, impossible-travel/session anomalies, unusual browser child processes, and sandbox escape attempts become much more visible.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public active exploitation evidence found in reviewed sources and not listed in CISA KEV as of 2026-06-08.
Public PoC availabilityNo credible public PoC located in reviewed sources. Assume weaponization would be private, custom, and reliability-sensitive.
EPSS0.00047 from the prompt's intel block, which is very low modeled near-term exploitation probability. FIRST percentile was not independently verified in primary sources reviewed.
KEV statusNot KEV-listed; no CISA KEV date applies.
CVSS vector meaningCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H means remote reach via web content with no auth required, but still requires user interaction and assumes very high downstream impact if exploitation succeeds.
Affected versionsChrome prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/.54 on Windows/macOS.
Fixed versionsFixed in 149.0.7827.53 (Linux) and 149.0.7827.53/.54 (Windows/macOS). For Chrome, think browser update level, not distro-style backport semantics.
Exposure realityThis is client-side browser attack surface, not an internet-exposed listening service. Shodan/Censys/FOFA-style counts are not meaningful here; your exposure is your managed desktop fleet and any unmanaged browsers still below the fixed build.
Disclosure timelineGoogle's stable release note was published 2026-06-02; your supplied disclosure date is 2026-06-04. Use both dates in tracking so teams do not argue over when the clock started.
Reporter / component contextGoogle's release notes say the bug was reported by Google on 2026-05-17 and sits in Dawn, the Chromium WebGPU stack.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to HIGH (8.0/10)

The decisive downgrader is that this is still a user-driven browser exploit path, not an unauthenticated server-side foothold, and a single Dawn bug usually does not equal immediate full-host compromise without an additional containment break. It stays HIGH because Chrome is broadly deployed, hostile web content is easy to deliver at scale, and the target population is your entire browsing fleet rather than a niche appliance subset.

HIGH Affected version range and fixed builds
MEDIUM Real-world impact beyond browser context due to limited public bug detail
HIGH No KEV listing or public exploitation evidence in reviewed sources

Why this verdict

  • User interaction is a real tax: the attacker must get a human onto hostile content first, which is materially different from a remotely reachable service bug and pushes the score down from the raw 9.6 baseline.
  • Likely needs a second win: a Dawn/WebGPU issue is dangerous, but enterprise pain usually requires either a sandbox escape or valuable in-browser session theft; that post-exploitation dependency is another explicit downward adjustment.
  • Field evidence is cold: no KEV entry, no reviewed public PoC, and an EPSS of 0.00047 all argue against treating this like an active emergency right now.
  • Ubiquity prevents a bigger downgrade: Chrome is everywhere, so even a non-KEV browser bug with friction still has a large reachable population and deserves real patch attention.

Why not higher?

It is not CRITICAL because there is no reviewed evidence of active exploitation, no public weaponized PoC, and no proof in the reviewed sources that this single CVE reliably yields full host compromise by itself. The browser process model and the need for a user visit are meaningful friction, not paperwork friction.

Why not lower?

It is not MEDIUM because the trigger is ordinary web content against one of the most widely deployed enterprise applications on the planet. If your users browse the internet, the exposure population is massive, and the impact of a successful browser exploit is still serious even before you assume a perfect sandbox escape.

05 · Compensating Control

What to do — in priority order.

  1. Force Chrome onto the fixed build — Use enterprise browser management, software deployment, or endpoint management to push 149.0.7827.53/.54 or later and force relaunch where policy allows. For a HIGH verdict, deploy this control within 30 days if patching is not yet complete, because version drift is the real exposure amplifier in big fleets.
  2. Block stale browser versions from sensitive apps — At your IdP, proxy, or access gateway, deny or step-up-auth sessions from Chrome builds below the fixed version for admin portals, email, and high-value SaaS. This reduces the value of any successful client-side exploit and should be in place within 30 days for users who cannot patch immediately.
  3. Use browser isolation for high-risk groups — Route executives, admins, developers, and click-prone populations through remote browser isolation or similarly hardened browsing paths for untrusted destinations. This is a practical blast-radius reducer when patch completion lags; stand it up within 30 days where already available.
  4. Disable the vulnerable feature path where feasible — If your business does not need WebGPU/Dawn-dependent workflows, use managed browser settings to restrict that capability on high-risk or slow-to-patch cohorts. This is a targeted mitigation, not a universal answer, and should be applied within 30 days only where app compatibility has been checked.
What doesn't work
  • Network IPS signatures do not solve this well, because the exploit lives in browser-handled HTML/JavaScript over normal web traffic and usually inside HTTPS.
  • Email filtering alone is insufficient, because the lure can arrive via ads, SEO poisoning, chat, docs, or compromised legitimate sites.
  • AV-only thinking is weak here; file-based malware prevention may never see the exploit stage if everything happens in-browser.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or via your EDR live-response shell, not from a central scanner. Invoke it with python3 check_cve_2026_10983.py on macOS/Linux or py check_cve_2026_10983.py on Windows; no admin rights are usually needed, though elevated rights may improve path coverage on locked-down systems.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# Check Google Chrome version exposure for CVE-2026-10983
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import shutil
import subprocess
import sys
from typing import List, Optional, Tuple

TARGET_LINUX = (149, 0, 7827, 53)
TARGET_WIN_MAC = (149, 0, 7827, 53)


def parse_version(text: str) -> Optional[Tuple[int, int, int, int]]:
    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_str(v: Tuple[int, int, int, int]) -> str:
    return '.'.join(str(x) for x in v)


def run_cmd(cmd: List[str]) -> Optional[str]:
    try:
        out = subprocess.check_output(cmd, stderr=subprocess.STDOUT, text=True, timeout=10)
        return out.strip()
    except Exception:
        return None


def find_windows_versions() -> List[Tuple[str, Tuple[int, int, int, int]]]:
    results = []
    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'),
    ]
    ps = shutil.which('powershell') or shutil.which('pwsh')
    for p in paths:
        if os.path.exists(p) and ps:
            cmd = [ps, '-NoProfile', '-Command', f"(Get-Item '{p}').VersionInfo.ProductVersion"]
            out = run_cmd(cmd)
            v = parse_version(out or '')
            if v:
                results.append((p, v))
    return results


def find_macos_versions() -> List[Tuple[str, Tuple[int, int, int, int]]]:
    results = []
    paths = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
    ]
    for p in paths:
        if os.path.exists(p):
            out = run_cmd([p, '--version'])
            v = parse_version(out or '')
            if v:
                results.append((p, v))
    return results


def find_linux_versions() -> List[Tuple[str, Tuple[int, int, int, int]]]:
    results = []
    candidates = ['google-chrome', 'google-chrome-stable', 'chrome', 'chromium', 'chromium-browser']
    seen = set()
    for c in candidates:
        exe = shutil.which(c)
        if exe and exe not in seen:
            seen.add(exe)
            out = run_cmd([exe, '--version'])
            v = parse_version(out or '')
            if v:
                results.append((exe, v))
    return results


def compare(v1: Tuple[int, int, int, int], v2: Tuple[int, int, int, int]) -> int:
    return (v1 > v2) - (v1 < v2)


def main() -> int:
    system = platform.system().lower()
    found: List[Tuple[str, Tuple[int, int, int, int]]] = []

    if 'windows' in system:
        found = find_windows_versions()
        target = TARGET_WIN_MAC
    elif 'darwin' in system:
        found = find_macos_versions()
        target = TARGET_WIN_MAC
    elif 'linux' in system:
        found = find_linux_versions()
        target = TARGET_LINUX
    else:
        print('UNKNOWN: unsupported operating system for this check')
        return 2

    if not found:
        print('UNKNOWN: Google Chrome not found in standard locations')
        return 2

    # Evaluate the highest discovered version in case multiple installs exist.
    highest_path, highest_ver = max(found, key=lambda x: x[1])

    if compare(highest_ver, target) >= 0:
        print(f'PATCHED: found {version_str(highest_ver)} at {highest_path}; fixed baseline is {version_str(target)} or later')
        return 0
    else:
        print(f'VULNERABLE: found {version_str(highest_ver)} at {highest_path}; requires {version_str(target)} or later')
        return 1


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

If you remember one thing.

TL;DR
Monday morning, treat this as a fleet-wide browser hygiene priority, not a midnight incident: inventory Chrome versions immediately, identify any endpoints still below 149.0.7827.53/.54, and use access controls or feature restriction on laggards. Under the noisgate mitigation SLA, you have ≤30 days to put compensating controls in place for systems you cannot patch right away, and under the noisgate remediation SLA, you have ≤180 days to complete vendor patching; in practice for a browser this should land far earlier, but the reassessed severity does not justify dropping everything absent KEV or active exploitation evidence.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
  2. Google Chrome Releases - Early Stable Update for Desktop
  3. Chromium issue tracker entry referenced by the release note
  4. Chromium Security overview
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS project
  7. FIRST EPSS API documentation
  8. Chrome Enterprise - View Chrome version details
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.