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

Uninitialized Use in Dawn in Google Chrome on Windows prior to 149

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

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.

"Widely deployed browser, but this is a user-driven Windows-only data leak with no known exploitation or public weaponization."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Deliver a malicious page with a custom WebGPU/Dawn trigger

The attacker hosts or injects a crafted HTML/JavaScript page designed to exercise the vulnerable Dawn code path. No authentication is needed, but the victim must render attacker-controlled content in vulnerable Chrome on Windows. Public exploit tooling was not found in the reviewed sources, so assume a bespoke harness rather than commodity kit.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Network scanners will not find this. Detection is mostly indirect: secure web gateway telemetry, browser crash spikes, suspicious page referrals, and version inventory from EDR or Chrome Enterprise.
STEP 02

Trigger uninitialized memory use inside Dawn

The crafted page coerces the browser into using uninitialized memory in Dawn. Based on the CNA text, the result is information disclosure rather than process takeover: data can bleed across origin boundaries if the bad state is reached. This is materially weaker than the many Chrome memory-safety bugs that end in renderer or browser RCE.
Conditions required:
  • The exploit reliably reaches the vulnerable memory state
  • The browser process contains useful cross-origin data to expose
Where this breaks in practice:
  • 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
Detection/coverage: Exploit prevention products may see abnormal browser behavior, but signature coverage is uncertain without a public PoC or published IOCs.
STEP 03

Extract cross-origin data of value

If exploitation succeeds, the attacker can leak data that should be segregated by the same-origin model, such as page content or tokens present in the victim's browsing context. The blast radius is the user session, not the endpoint or domain estate as a whole. That matters: this is a targeted session-compromise primitive, not a fleet-wide takeover primitive.
Conditions required:
  • Victim is simultaneously authenticated to a target web application or has sensitive data in browser context
  • Leaked data is actually actionable to the attacker
Where this breaks in practice:
  • 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
Detection/coverage: Look for downstream session abuse, anomalous SaaS access, impossible travel, and token replay rather than host-level exploit artifacts alone.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusAs of 2026-06-05, I found no Google statement of active exploitation and no CISA KEV listing for this CVE.
Proof-of-concept availabilityNo 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.
EPSS0.00035 per your intel. That is extremely low probability in practical prioritization terms; percentile was not confirmed from the browsed sources.
KEV statusNot listed in CISA's KEV catalog as of 2026-06-05.
CVSS vectorCVSS: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 versionsGoogle/Chrome CNA text says Google Chrome on Windows prior to 149.0.7827.53.
Fixed versionsStable 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 realityThis 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 dateThe CVE record was published on 2026-06-04; Chrome 149 stable release notes show the release date as 2026-06-02.
ReporterA 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.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (5.6/10)

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.

HIGH Affected version range and vendor baseline
MEDIUM Real-world exploitability details inside the Dawn code path
HIGH No-KEV / no-public-PoC status as of 2026-06-05

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# 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
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not treat this like a zero-day fire drill; treat it like a widely deployed client-side medium that should ride your normal Chrome governance path. For this MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window and make sure Windows Chrome fleets are converging to 149.0.7827.53+ under policy, with relaunch enforcement for stragglers; the noisgate remediation SLA is ≤ 365 days, but in practice for browser fleets you should verify auto-update health and close out stale unmanaged installs on the next routine endpoint cycle, not next quarter.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop
  2. Chrome 149 Release Notes
  3. Government of Canada Cyber Centre Advisory AV26-544
  4. CIRCL Vulnerability-Lookup entry for CVE-2026-11101
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS Overview
  7. Chrome Enterprise - Release Channels
  8. Chrome Enterprise - Manage Chrome Updates
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.