This is a second-story window, not the front door
CVE-2026-10940 is a race condition in Chrome's Codecs component on Windows that affects versions before 149.0.7827.53. The bug matters because it appears to let an attacker who already has code execution or strong control inside the renderer process use a crafted media path to push past Chrome's sandbox boundary; in plain English, this is not the bug that gets you *into* the browser, it's the bug that may help you get *out of* the renderer jail once you're already there.
Google's HIGH 8.3 label is defensible in a lab because sandbox escapes can turn a browser exploit into host impact, but it overstates fleet urgency for patch prioritization. The decisive real-world friction is the prerequisite: the attacker must first compromise the renderer, which means this CVE is a post-initial-compromise exploit-chain component, not a standalone remote compromise path across 10,000 endpoints.
4 steps from start to impact.
Land a renderer foothold with a separate bug
- Target is running vulnerable Chrome on Windows
- User is driven to attacker-controlled content
- Attacker has a separate working renderer exploit
- Requires chaining at least one more vulnerability before this CVE matters
- Modern Safe Browsing, site isolation, and exploit mitigations raise the bar for the first-stage renderer bug
- No public evidence located that this CVE is being used as part of active chains
Steer execution into the vulnerable Codecs path
- Windows-specific affected build is present
- Victim session can process attacker-controlled media
- Exploit chain can reach the Codecs subsystem from the compromised renderer
- Windows-only scope cuts the reachable population versus all-platform Chrome bugs
- Crafted media path narrows exposure compared with generic HTML/JS-only triggers
- Race conditions are notoriously less reliable outside tuned lab conditions
Win the race and break sandbox assumptions
- Exploit timing is stable enough on the target hardware and browser build
- The crafted media object reaches the vulnerable synchronization path
- Browser and OS mitigations do not fully blunt the primitive
- Race exploitation reliability degrades across hardware, load, and patch-level variance
- Windows mitigations such as AppContainer hardening, CFG, CET, and sandbox policy reduce exploit engineering room
- A crash-only outcome is easier to hit than a clean sandbox escape
Convert sandbox escape into host impact
- Successful sandbox escape primitive
- Useful post-escape code execution or privilege gain
- Endpoint controls fail to contain follow-on actions
- This is still not kernel compromise; follow-on privilege escalation may be needed for full host control
- EDR often catches the noisier post-escape behaviors better than the browser exploit itself
- Blast radius is per-user-session unless combined with additional escalation or credential theft
- A WAF does not solve this; the vulnerable surface is a client-side browser/media path, not your web server.
- Perimeter IPS/IDS is weak here because there is no stable network signature for a renderer-compromise-plus-race-condition chain.
- MFA is still good hygiene, but it does nothing to stop a browser sandbox escape on the endpoint itself.
The supporting signals.
| In-the-wild status | No confirmed public exploitation located as of 2026-06-05, and the user-provided intel says KEV: No. |
|---|---|
| Proof-of-concept availability | No public PoC located. That matters because this bug is already a chain component; an attacker still needs a renderer foothold before this CVE has value. |
| EPSS | 0.00061 (~0.061%), which is extremely low and lines up with a bug that is hard to weaponize at scale. |
| KEV status | Not listed in the CISA KEV catalog. |
| CVSS vector | CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H — the score assumes severe impact, but the AC:H + UI:R and hidden prerequisite of a renderer compromise are the real drag in enterprise conditions. |
| Affected versions | Google Chrome on Windows prior to 149.0.7827.53. |
| Fixed versions | 149.0.7827.53/54 for Windows/Mac and 149.0.7827.53 for Linux were announced in Google's release flow; this CVE is described as Windows-specific. |
| Release timing | Google pushed 149.0.7827.53/.54 as an early stable release to a small percentage of desktop users on May 29, 2026; Canada's Cyber Centre referenced the advisory on June 3, 2026. |
| Exposure and scanning reality | Not internet-scannable in any meaningful Shodan/Censys/FOFA sense. This is endpoint software, so exposure must be measured from asset inventory, EDR, browser management, or software deployment telemetry. |
| Researcher / disclosure detail | Public bug details appear limited at disclosure time, which is normal for Chrome security fixes. The exact bug internals and reporter are not clearly exposed in the sources I could verify. |
Sources.
- Google Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
- Google Chrome Releases blog
- Canadian Centre for Cyber Security advisory AV26-544
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS overview
- FIRST EPSS API documentation
- Vulnerability-Lookup Chrome June 2026 search results
- Vulnerability-Lookup Chrome June 2026 search results (additional page)
Why this verdict
- Biggest downgrade: requires renderer compromise first — attacker position is not unauthenticated remote code execution on the host; it implies a prior successful browser exploit and therefore a chained attack, not an entry path.
- Reach is narrower than the vendor score suggests — Windows-only exposure plus a crafted media/codecs path means only a subset of Chrome endpoints and browsing flows are even relevant.
- Threat intel is quiet — no KEV listing, no confirmed public campaigns, and an EPSS of 0.00061 argue against treating this like an internet-scale burn-now item.
Why not higher?
A higher rating would require one of three amplifiers that are missing here: proven in-the-wild exploitation, public weaponization, or a standalone remote compromise path. Instead, this bug starts from a compromised renderer and then asks the attacker to win a race condition on Windows, which is a much smaller and less reliable slice of real-world exposure.
Why not lower?
I am not dropping this to LOW because Chrome is ubiquitous and sandbox escapes are strategically valuable even when they are chain-dependent. If an attacker already has renderer execution, a working escape can materially change the outcome on an endpoint from a contained browser compromise to host-impacting access.
Crowdsourced verification payload.
Run this on the target Windows host or through your endpoint management tool. Invoke it with powershell.exe -ExecutionPolicy Bypass -File .\check-chrome-cve-2026-10940.ps1; no admin rights are required because it only reads file and registry metadata. It checks common system- and user-level Chrome install paths and reports VULNERABLE, PATCHED, or UNKNOWN.
# check-chrome-cve-2026-10940.ps1
# Purpose: Detect whether Google Chrome on Windows is older than 149.0.7827.53
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
$ErrorActionPreference = 'SilentlyContinue'
$fixedVersion = [version]'149.0.7827.53'
function Get-ChromeCandidates {
$paths = New-Object System.Collections.Generic.List[string]
$envPaths = @(
"$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
"$env:ProgramFiles(x86)\Google\Chrome\Application\chrome.exe",
"$env:LocalAppData\Google\Chrome\Application\chrome.exe"
)
foreach ($p in $envPaths) {
if ($p -and (Test-Path $p)) { [void]$paths.Add($p) }
}
$regKeys = @(
'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 ($key in $regKeys) {
$defaultValue = (Get-Item $key).GetValue('')
if ($defaultValue -and (Test-Path $defaultValue)) { [void]$paths.Add($defaultValue) }
}
return $paths | Sort-Object -Unique
}
function Get-FileVersionObject([string]$path) {
try {
$fv = (Get-Item $path).VersionInfo.FileVersion
if (-not $fv) { return $null }
$parts = ($fv -split '[^0-9]+' | Where-Object { $_ -match '^\d+$' })
if ($parts.Count -lt 4) { return $null }
return [version]("{0}.{1}.{2}.{3}" -f $parts[0], $parts[1], $parts[2], $parts[3])
}
catch {
return $null
}
}
$candidates = Get-ChromeCandidates
if (-not $candidates -or $candidates.Count -eq 0) {
Write-Output 'UNKNOWN'
exit 2
}
$foundAnyVersion = $false
$foundVulnerable = $false
$results = @()
foreach ($chrome in $candidates) {
$ver = Get-FileVersionObject $chrome
if ($ver -ne $null) {
$foundAnyVersion = $true
$state = if ($ver -lt $fixedVersion) { 'VULNERABLE' } else { 'PATCHED' }
$results += [pscustomobject]@{
Path = $chrome
Version = $ver.ToString()
State = $state
}
if ($ver -lt $fixedVersion) { $foundVulnerable = $true }
}
}
if (-not $foundAnyVersion) {
Write-Output 'UNKNOWN'
exit 2
}
# Optional detail for management tooling logs
$results | ForEach-Object { Write-Verbose ($_.Path + ' -> ' + $_.Version + ' -> ' + $_.State) }
if ($foundVulnerable) {
Write-Output 'VULNERABLE'
exit 1
}
else {
Write-Output 'PATCHED'
exit 0
}