This is a peephole in a moving train, not a blown-out door
CVE-2026-11101 is an uninitialized-use bug in Chrome's Dawn component on Windows, affecting Google Chrome versions prior to 149.0.7827.53. Dawn is Chromium's WebGPU implementation layer, so the practical story is a malicious web page steering a vulnerable browser into exposing data it should keep isolated across origins; the stated impact is cross-origin data leakage, not code execution or persistence.
Google's MEDIUM 6.5 baseline is directionally right, but a little generous once you audit the real attack chain. The attacker is remote and unauthenticated, but still needs a user to browse attacker-controlled content, the flaw is Windows-only, the known impact is confidentiality-only, and there is no KEV entry, no public exploitation claim, and no public PoC in the source set. That keeps this in the operationally important-but-not-fire-drill bucket.
3 steps from start to impact.
Deliver a malicious page with a custom WebGPU/Dawn trigger
- Victim uses Chrome on Windows below 149.0.7827.53
- Victim visits attacker-controlled or attacker-influenced content
- The vulnerable Dawn code path is reachable during page rendering
- Requires user interaction (
UI:R), so this is not a wormable edge-service bug - Windows-only scope removes macOS/Linux fleet exposure
- No public PoC located, which raises attacker development cost
Trigger uninitialized memory use inside Dawn
- The exploit reliably reaches the vulnerable memory state
- The browser process contains useful cross-origin data to expose
- Memory disclosure reliability is usually lower than a straight logic flaw
- Confidentiality impact depends on what is present in-process during exploitation
- Modern browser hardening and site isolation reduce clean, repeatable data harvest paths
Extract cross-origin data of value
- Victim is simultaneously authenticated to a target web application or has sensitive data in browser context
- Leaked data is actually actionable to the attacker
- Impact is bounded to browser-session confidentiality, not arbitrary code execution
- Attack payoff varies heavily with user role and what apps are open
- MFA, device binding, and short-lived tokens can reduce post-leak usefulness
The supporting signals.
| In-the-wild status | As of 2026-06-05, I found no Google statement of active exploitation and no CISA KEV listing for this CVE. |
|---|---|
| Proof-of-concept availability | No public PoC or named exploit repo was found in the reviewed source set. The Chromium issue reference exists, but no public weaponized code was identified. |
| EPSS | 0.00035 per your intel. That is extremely low probability in practical prioritization terms; percentile was not confirmed from the browsed sources. |
| KEV status | Not listed in CISA's KEV catalog as of 2026-06-05. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — remote and easy to reach once a user visits the page, but user interaction is mandatory and the stated impact is confidentiality-only. |
| Affected versions | Google/Chrome CNA text says Google Chrome on Windows prior to 149.0.7827.53. |
| Fixed versions | Stable desktop fix is 149.0.7827.53/54 for Windows/macOS, with 149.0.7827.53 for Linux. For Windows enterprises on Extended Stable, Google also published 148.0.7778.254 on 2026-06-03; it is a security-servicing build, though the per-CVE backport for this exact issue was not explicitly enumerated in the source set. |
| Exposure/scanning reality | This is a client-side browser bug, so Shodan/Censys/FOFA-style internet exposure counts are not meaningful. GreyNoise-style edge exploitation telemetry is likewise a poor fit unless campaigns are observed via exploit infrastructure; none was identified here. |
| Disclosure date | The CVE record was published on 2026-06-04; Chrome 149 stable release notes show the release date as 2026-06-02. |
| Reporter | A public individual reporter name was not exposed in the browsed sources. The CVE was assigned by the Chrome CNA; attribution appears withheld or not yet public. |
noisgate verdict.
The single biggest downward driver is mandatory user interaction combined with confidentiality-only impact. This is a browser-session data leak on vulnerable Windows clients, not a pre-auth service exploit or an endpoint takeover, and there is no active-exploitation signal pushing it upward.
Why this verdict
- Downward pressure: requires
UI:R— the attacker must get a user onto malicious content, which sharply reduces reach compared with edge-exposed or zero-click browser bugs. - Downward pressure: Windows-only — this is not cross-platform Chrome exposure, so a mixed OS fleet immediately sheds part of the vulnerable population.
- Downward pressure: confidentiality-only — the vendor describes cross-origin data leakage, not renderer escape, arbitrary code execution, or persistence.
- Downward pressure: no exploitation evidence — not in KEV, no public Google statement of active abuse, and no public PoC found.
- Upward pressure: Chrome is everywhere — the product is ubiquitous, and browsers sit directly on untrusted content all day, so even a medium-grade info leak deserves clean inventory and normal update discipline.
Why not higher?
This is not an unauthenticated edge-service compromise, and it does not currently present as a reliable path to code execution. The attacker still needs a victim to render malicious content, and the impact described by the vendor stops at cross-origin disclosure rather than system compromise.
Why not lower?
It still hits a massively deployed client application that continuously parses hostile input from the internet. If exploited against the right user at the right time, cross-origin leakage can expose authenticated business data or session material, so writing it off as backlog noise would be too relaxed.
What to do — in priority order.
- Force Chrome relaunch for pending updates — If you already allow Chrome auto-update, the biggest practical gap is users sitting on a vulnerable process that has downloaded but not applied the fix. Use Chrome Enterprise relaunch notification policy to force restart completion; for a MEDIUM verdict there is no mitigation SLA, so this is a hygiene move, not an emergency control.
- Disable or restrict WebGPU for high-risk cohorts if patch lag exists — Because the flaw sits in
Dawn, restricting WebGPU use is a sensible temporary brake for privileged admins, finance users, executives, and unmanaged kiosk-like endpoints if you cannot confirm version uptake. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but use this when operational reality says browser updates lag. - Block unmanaged Chrome channels on corporate Windows endpoints — The real exposure is stale browsers outside normal enterprise servicing. Enforce managed Stable or approved Extended Stable via policy and software inventory so straggler user-installed copies do not sit below the fixed build; again, no mitigation SLA applies at MEDIUM, so align this with normal endpoint governance.
- Monitor for post-browser session abuse — Because the likely payoff is token or page-data theft, watch SaaS sign-ins, token replay, and unusual session reuse from roles with access to sensitive web apps. This does not replace patching, but it helps catch the impact path this CVE actually enables.
- A WAF does not meaningfully help when the vulnerable parser is the user's browser rendering attacker-controlled content from any site.
- Traditional internet attack-surface scans will not surface this exposure because Chrome is a client, not an edge service.
- EDR alone is not a reliable compensating control for a confidentiality-focused browser memory disclosure; it may see follow-on abuse, but not necessarily the exploit itself.
Crowdsourced verification payload.
Run this on the target Windows endpoint or through your RMM/EDR remote shell. Invoke with powershell -ExecutionPolicy Bypass -File .\check-chrome-cve-2026-11101.ps1; local admin is not required for standard install paths, but it improves coverage if multiple-user installations exist. The script checks common Chrome executable locations and prints VULNERABLE, PATCHED, or UNKNOWN.
# check-chrome-cve-2026-11101.ps1
# Purpose: Determine likely exposure to CVE-2026-11101 on Windows Chrome installs.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
$ErrorActionPreference = 'SilentlyContinue'
function Get-VersionObject {
param([string]$v)
try { return [version]$v } catch { return $null }
}
# Vendor-confirmed fixed build for stable desktop Windows
$FixedStable = Get-VersionObject '149.0.7827.53'
# Extended Stable security build published on 2026-06-03; exact per-CVE backport was not explicitly confirmed in reviewed sources
$ExtendedStableBuild = Get-VersionObject '148.0.7778.254'
$Paths = @(
"$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
"$env:ProgramFiles(x86)\Google\Chrome\Application\chrome.exe",
"$env:LocalAppData\Google\Chrome\Application\chrome.exe"
) | Select-Object -Unique
$Found = @()
foreach ($p in $Paths) {
if (Test-Path $p) {
$item = Get-Item $p
$ver = $item.VersionInfo.ProductVersion
if (-not $ver) { $ver = $item.VersionInfo.FileVersion }
$Found += [pscustomobject]@{ Path = $p; Version = $ver; VersionObj = (Get-VersionObject $ver) }
}
}
if ($Found.Count -eq 0) {
Write-Output 'UNKNOWN: Chrome executable not found in common install paths.'
exit 2
}
$AnyVuln = $false
$AnyPatched = $false
$AnyUnknown = $false
foreach ($f in $Found) {
if (-not $f.VersionObj) {
Write-Output ("UNKNOWN: Could not parse version at {0} ({1})" -f $f.Path, $f.Version)
$AnyUnknown = $true
continue
}
if ($f.VersionObj -ge $FixedStable) {
Write-Output ("PATCHED: {0} -> {1} (>= 149.0.7827.53)" -f $f.Path, $f.Version)
$AnyPatched = $true
continue
}
# Handle the published Extended Stable servicing build conservatively.
if ($f.VersionObj.Major -eq 148 -and $f.VersionObj -ge $ExtendedStableBuild) {
Write-Output ("UNKNOWN: {0} -> {1} is an Extended Stable-era build; confirm channel policy/backport status in management records." -f $f.Path, $f.Version)
$AnyUnknown = $true
continue
}
Write-Output ("VULNERABLE: {0} -> {1} (< 149.0.7827.53 and not a confirmed patched Extended Stable build)" -f $f.Path, $f.Version)
$AnyVuln = $true
}
if ($AnyVuln) { exit 1 }
if ($AnyUnknown -and -not $AnyPatched) { exit 2 }
if ($AnyUnknown -and $AnyPatched) {
Write-Output 'UNKNOWN: Mixed state detected; at least one install is patched, but another could not be fully classified.'
exit 2
}
Write-Output 'PATCHED'
exit 0
If you remember one thing.
Sources
- Google Chrome Releases - Stable Channel Update for Desktop
- Chrome 149 Release Notes
- Government of Canada Cyber Centre Advisory AV26-544
- CIRCL Vulnerability-Lookup entry for CVE-2026-11101
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS Overview
- Chrome Enterprise - Release Channels
- Chrome Enterprise - Manage Chrome Updates
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.