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.
4 steps from start to impact.
Land code in the renderer first
- 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
- 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
Reach the vulnerable Codecs path
- Renderer can invoke the relevant Codecs functionality
- Attacker can shape media state or object lifetime precisely enough to hit the freed object
- 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
Turn memory corruption into a useful boundary break
- Exploit primitive is stable enough for target fleet builds
- Attacker can bypass or work around Chrome and Windows exploit mitigations
- 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
Cash out on host impact
- Successful chaining from renderer compromise through the Codecs bug
- Ability to stage payloads or abuse local trust after escape
- 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
The supporting signals.
| In-the-wild status | No 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 availability | No public PoC or weaponized GitHub repo found in reviewed public sources for this specific CVE as of 2026-06-06. |
| EPSS | 0.00035 from the supplied intel. That is floor-level exploit probability and argues strongly against emergency handling. |
| KEV status | Not listed in the CISA Known Exploited Vulnerabilities Catalog. |
| Vendor severity mismatch | The 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 check | Supplied 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 versions | Google Chrome on Windows before 149.0.7827.53 per the supplied title/intel. |
| Fixed versions | Patch 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 data | Shodan/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 reporting | Disclosed 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. |
noisgate verdict.
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.
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.00035is 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.
What to do — in priority order.
- 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. - 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.
- Hunt for Chrome crash anomalies — Pull Windows Error Reporting, EDR, and Chrome crash telemetry for sudden spikes in
chrome.exeor 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. - 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.
- 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.6at face value would over-prioritize a bug whose main real-world friction is post-compromise attacker position.
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.
# 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
}
If you remember one thing.
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
- Google Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
- Google Chrome Releases index for 2026
- Chromium Security overview
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS overview
- FIRST EPSS API documentation
- MITRE CWE-416: Use After Free
- Chromium issue tracker reference for CVE-2026-11094
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.