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

Use after free in Codecs in Google Chrome on Windows prior to 149

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

This is a second lock on the vault door, not the front gate

CVE-2026-11094 is a CWE-416 use-after-free in Chrome's Codecs component affecting Google Chrome on Windows before 149.0.7827.53. The important real-world detail is the attack position implied by the title you supplied: this is not the initial browser compromise, but a post-renderer-compromise bug that helps an attacker who already landed code in the renderer try to move farther toward a sandbox escape or stronger host impact.

Google's own June 2, 2026 Chrome 149 advisory classifies CVE-2026-11094 as Medium, not Critical, and that matches reality better than the prompt's 9.6 label. Requiring a compromised renderer is massive friction: it means the attacker already needs a separate bug or chain stage first, blast radius is one endpoint at a time, there is no KEV listing, and the supplied EPSS 0.00035 is basically background noise rather than an active-crime signal.

"This looks like a chain component, not a fleet-wide emergency: it needs prior renderer compromise and has no exploitation signal."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land code in the renderer first

The attacker still needs an initial browser exploit chain to get controlled execution in Chrome's renderer process. In practice that means a separate memory-corruption, type-confusion, UXSS, or logic bug delivered through a malicious site, ad, or document; there is no public weaponized tool tied to CVE-2026-11094 itself in the sources reviewed.
Conditions required:
  • Victim uses Chrome on Windows prior to 149.0.7827.53
  • Victim opens attacker-controlled web content
  • Attacker has a separate working renderer compromise stage
Where this breaks in practice:
  • This prerequisite alone makes the bug post-initial-compromise
  • Site Isolation, sandboxing, and modern browser hardening make reliable renderer exploitation non-trivial
  • No public in-the-wild reporting or KEV signal lowers operational confidence for attackers
Detection/coverage: Traditional vuln scanners will not see this step. Detection comes from browser exploit telemetry, crash spikes, EDR memory-corruption signals, and malicious site intelligence.
STEP 02

Reach the vulnerable Codecs path

Once inside the renderer, the attacker must exercise the Codecs code path and trigger the use-after-free with a precise object lifetime sequence. Because the bug is in Codecs on Windows, exploitability depends on the target actually hitting the affected media/codec handling path under attacker-controlled conditions.
Conditions required:
  • Renderer can invoke the relevant Codecs functionality
  • Attacker can shape media state or object lifetime precisely enough to hit the freed object
Where this breaks in practice:
  • Not every browsing session exercises the vulnerable path
  • Media and codec handling bugs are often sensitive to file type, timing, and target build details
  • Exploit reliability usually degrades across hardware, drivers, and Windows versions
Detection/coverage: Coverage is weak for scanners; defenders are more likely to see renderer or utility-process crashes, Windows Error Reporting events, or abnormal Chrome crash telemetry.
STEP 03

Turn memory corruption into a useful boundary break

A use-after-free is only the primitive; the attacker still has to convert it into controlled code execution or a usable sandbox-bypass effect. On modern Windows Chrome, that usually means surviving allocator randomness and browser exploit mitigations before any meaningful privilege or boundary transition happens.
Conditions required:
  • Exploit primitive is stable enough for target fleet builds
  • Attacker can bypass or work around Chrome and Windows exploit mitigations
Where this breaks in practice:
  • Windows exploit mitigations, browser sandboxing, and process separation materially raise cost
  • Reliability at scale is hard without deep target-specific tuning
  • Single-host execution value is lower unless paired with credential theft or follow-on tooling
Detection/coverage: EDR may catch abnormal memory access patterns, exploit-guard events, or suspicious post-crash relaunch behavior, but there is no straightforward network signature.
STEP 04

Cash out on host impact

If the chain works, the attacker upgrades a browser foothold into stronger code execution or a sandbox escape on that endpoint. That is serious for a targeted intrusion, but it is still one chain stage in a client-side attack, not an internet-scale unauthenticated service exploit.
Conditions required:
  • Successful chaining from renderer compromise through the Codecs bug
  • Ability to stage payloads or abuse local trust after escape
Where this breaks in practice:
  • Per-endpoint exploitation limits blast radius
  • Enterprise EDR, browser isolation, and least-privilege on workstations can contain damage
  • No evidence in the reviewed sources of mass scanning, wormability, or opportunistic crimeware use
Detection/coverage: Look for suspicious child processes from Chrome, token/handle abuse after browser activity, anomalous persistence writes, and EDR detections for browser-to-OS boundary crossing.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo current active-exploitation signal found. Google did not flag this release item as exploited, and CVE-2026-11094 is not in CISA KEV.
Proof-of-concept availabilityNo public PoC or weaponized GitHub repo found in reviewed public sources for this specific CVE as of 2026-06-06.
EPSS0.00035 from the supplied intel. That is floor-level exploit probability and argues strongly against emergency handling.
KEV statusNot listed in the CISA Known Exploited Vulnerabilities Catalog.
Vendor severity mismatchThe prompt says CRITICAL 9.6, but Google's official Chrome 149 advisory lists CVE-2026-11094 as Medium. For this CVE, the vendor's published bucket is the better baseline.
CVSS vector reality checkSupplied vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H. That vector describes headline impact, but it overstates operational risk if the bug really requires a previous renderer compromise.
Affected versionsGoogle Chrome on Windows before 149.0.7827.53 per the supplied title/intel.
Fixed versionsPatch to Chrome 149.0.7827.53 or later on Windows. Google's desktop stable post announces 149.0.7827.53/54 for Windows/Mac on 2026-06-02.
Scanning and exposure dataShodan/Censys/FOFA/GreyNoise are poor fit here. Chrome is endpoint client software, not a network-listening appliance, so internet scan counts do not measure exposure; use EDR/SCCM/Intune/software inventory instead.
Disclosure and reportingDisclosed 2026-06-04 in CVE publication feeds; Google's Chrome 149 stable post shipped the fix on 2026-06-02 and says the issue was reported by Google on 2026-04-07.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.9/10)

The decisive factor is attacker position: this bug appears to require a pre-existing renderer compromise, which makes it a chain-enabler rather than a first-hop fleet-wide compromise vector. With no KEV entry, no public exploitation evidence, and a very low EPSS, this is important patch hygiene for a ubiquitous browser but not an interrupt-everything event.

HIGH Downgrade from the prompt's CRITICAL/9.6 claim
MEDIUM Assessment that the real-world attack path is post-renderer-compromise

Why this verdict

  • Major downward adjustment: requires prior renderer compromise — that means the attacker already completed the hard part of the browser attack chain before this CVE matters.
  • No exploitation signal — not KEV-listed, no Google zero-day statement, and supplied EPSS 0.00035 is nowhere near emergency territory.
  • Client-side, per-endpoint blast radius — this is a workstation/browser problem, not an internet-facing service flaw that can be sprayed across the fleet in one sweep.

Why not higher?

If this were a one-click remote browser-to-host escape with active exploitation, the verdict would move up fast. But the prerequisite chain is too restrictive: user interaction plus a separate renderer compromise plus a reliable second-stage exploit is not how broad opportunistic abuse usually scales.

Why not lower?

This is still a browser memory-corruption bug in Chrome on Windows, which is a very large exposure population in enterprise fleets. If an attacker already has a renderer foothold, a sandbox-adjacent codec bug can be high-value for targeted follow-on intrusion, so it does not belong in backlog-ignore territory.

05 · Compensating Control

What to do — in priority order.

  1. Enforce auto-update — Make sure Chrome stable auto-update is not being deferred or broken by policy, and confirm Windows endpoints are converging on 149.0.7827.53+. For a MEDIUM verdict there is no noisgate mitigation SLA; use this as normal hardening while you work inside the remediation window.
  2. Use browser isolation for risky users — Keep high-risk roles such as admins, finance, executives, and research staff in remote/browser isolation where feasible. This does not remove the bug, but it cuts the value of renderer-to-host chains while you remediate inside the 365-day window.
  3. Hunt for Chrome crash anomalies — Pull Windows Error Reporting, EDR, and Chrome crash telemetry for sudden spikes in chrome.exe or media/utility-process crashes after suspicious browsing events. There is no mitigation SLA for MEDIUM, so use this as a detection backstop rather than an emergency compensating action.
  4. Reduce local admin and privileged browsing — Keep daily browsing out of privileged sessions and remove unnecessary local admin rights so a successful browser chain has less room to cash out. This matters even when the bug is only a chain component.
What doesn't work
  • Perimeter IPS or WAF — this is a client-side browser bug, so network-edge controls do not reliably see or stop the exploit sequence.
  • Internet exposure scans — Shodan/Censys/FOFA will not tell you which endpoints are vulnerable because Chrome is not an exposed listening service.
  • CVSS-only sorting — treating the prompt's 9.6 at face value would over-prioritize a bug whose main real-world friction is post-compromise attacker position.
06 · Verification

Crowdsourced verification payload.

Run this on the target Windows endpoint or via your remote management tool. Example: powershell.exe -ExecutionPolicy Bypass -File .\check-chrome-cve-2026-11094.ps1; standard user rights are usually enough because it reads file/registry version data, but local admin helps when inventory paths are locked down.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# check-chrome-cve-2026-11094.ps1
# Purpose: Determine whether Google Chrome on Windows is vulnerable to CVE-2026-11094
# Logic: Versions lower than 149.0.7827.53 are VULNERABLE
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

$ErrorActionPreference = 'Stop'

function Get-VersionObject {
    param([string]$Version)
    try {
        return [version]$Version
    } catch {
        return $null
    }
}

function Get-ChromeVersion {
    $candidates = @(
        'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe',
        'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe',
        'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe'
    )

    foreach ($path in $candidates) {
        try {
            $item = Get-ItemProperty -Path $path -ErrorAction Stop
            if ($item.'(default)' -and (Test-Path $item.'(default)')) {
                $ver = (Get-Item $item.'(default)').VersionInfo.ProductVersion
                if ($ver) { return $ver }
            }
            if ($item.Path) {
                $exe = Join-Path $item.Path 'chrome.exe'
                if (Test-Path $exe) {
                    $ver = (Get-Item $exe).VersionInfo.ProductVersion
                    if ($ver) { return $ver }
                }
            }
        } catch {}
    }

    $fileCandidates = @(
        "$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
        "$env:ProgramFiles(x86)\Google\Chrome\Application\chrome.exe",
        "$env:LocalAppData\Google\Chrome\Application\chrome.exe"
    )

    foreach ($exe in $fileCandidates) {
        try {
            if (Test-Path $exe) {
                $ver = (Get-Item $exe).VersionInfo.ProductVersion
                if ($ver) { return $ver }
            }
        } catch {}
    }

    return $null
}

$fixed = Get-VersionObject '149.0.7827.53'
$current = Get-ChromeVersion

if (-not $current) {
    Write-Output 'UNKNOWN - Google Chrome not found or version could not be determined.'
    exit 2
}

$currentVersion = Get-VersionObject $current
if (-not $currentVersion) {
    Write-Output "UNKNOWN - Installed Chrome version '$current' could not be parsed."
    exit 2
}

if ($currentVersion -lt $fixed) {
    Write-Output "VULNERABLE - Installed Chrome version $current is older than 149.0.7827.53."
    exit 1
} else {
    Write-Output "PATCHED - Installed Chrome version $current is 149.0.7827.53 or newer."
    exit 0
}
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: do not treat this like a Chrome zero-day fire drill. Validate your Windows Chrome inventory, make sure auto-update is healthy, and roll the fleet to 149.0.7827.53+ through normal endpoint operations; for a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window. Using the disclosure date of 2026-06-04, your outer noisgate remediation SLA date is 2027-06-04; if you want a practical ops target, close browser stragglers this quarter and reserve true interrupt work for KEV-listed or actively exploited browser chains.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
  2. Google Chrome Releases index for 2026
  3. Chromium Security overview
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS overview
  6. FIRST EPSS API documentation
  7. MITRE CWE-416: Use After Free
  8. Chromium issue tracker reference for CVE-2026-11094
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.