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.
4 steps from start to impact.
Deliver a lure page
- 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
- 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
Reach the Dawn/WebGPU code path
- 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
- 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
Turn input validation failure into useful corruption
- 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
- 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
Escape browser confinement or monetize in-session access
- 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
- 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
The supporting signals.
| In-the-wild status | No public active exploitation evidence found in reviewed sources and not listed in CISA KEV as of 2026-06-08. |
|---|---|
| Public PoC availability | No credible public PoC located in reviewed sources. Assume weaponization would be private, custom, and reliability-sensitive. |
| EPSS | 0.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 status | Not KEV-listed; no CISA KEV date applies. |
| CVSS vector meaning | CVSS: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 versions | Chrome prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/.54 on Windows/macOS. |
| Fixed versions | Fixed 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 reality | This 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 timeline | Google'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 context | Google's release notes say the bug was reported by Google on 2026-05-17 and sits in Dawn, the Chromium WebGPU stack. |
noisgate verdict.
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.
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.
What to do — in priority order.
- 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.
- 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.
- 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.
- 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.
- 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.
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.
#!/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())
If you remember one thing.
Sources
- Google Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
- Google Chrome Releases - Early Stable Update for Desktop
- Chromium issue tracker entry referenced by the release note
- Chromium Security overview
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS project
- FIRST EPSS API documentation
- Chrome Enterprise - View Chrome version details
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.