This is a locked lobby door flaw that only matters after the intruder is already inside the building
CVE-2026-10933 is a use-after-free in Chrome Audio on Windows affecting builds before 149.0.7827.53. The key detail is the precondition in the advisory text: the attacker must have already compromised the renderer process. In plain English, this is not the bug that gets code running from a web page by itself; it is the bug that may help an attacker turn renderer code execution into a sandbox escape or broader browser compromise on Windows.
The vendor's HIGH 8.3 baseline is understandable if you score the memory corruption and post-exploit impact in isolation, but it overstates real enterprise urgency. The decisive friction is that this bug is post-initial-compromise within Chrome's exploit chain: no renderer compromise, no path. Add the low EPSS, no KEV listing, no public exploitation signal, and version-only detection, and this lands as MEDIUM for patch planning across a large fleet.
4 steps from start to impact.
Land code execution in a renderer
- Victim uses affected Chrome on Windows
- Attacker can get the user to load hostile content
- Attacker has a separate working renderer exploit
- This CVE is unusable without another bug in the chain
- Modern Chrome mitigations make stable renderer exploitation non-trivial
- User interaction is still required to reach attacker content
Trigger the Audio UAF from the compromised renderer
- Renderer is already compromised
- Target build is below 149.0.7827.53
- The exploit chain can reliably reach the affected Audio code path
- Reliability matters; many UAFs crash before they escape
- Exact trigger details are often withheld while Chromium bugs remain restricted
- Exploit developers still need heap shaping and version-specific tuning
Cross the sandbox boundary
- A reliable exploit primitive is achieved from the Audio UAF
- Chrome sandboxing is enabled normally
- No hardening or platform behavior breaks the exploit chain
- Chrome's sandbox and Site Isolation are explicitly designed to contain compromised renderers
- Post-renderer exploitation often fails due to broker policy, mitigations, or process crashes
- EDR memory-exploit protections may interrupt the chain even after renderer code exec
Abuse the widened foothold
- Successful sandbox escape
- Useful user context or reachable local assets
- Impact is bounded by user context and downstream controls
- App isolation, EDR, and credential protections can still reduce blast radius
The supporting signals.
| In-the-wild status | No current public exploitation signal found in the vendor release material, and no CISA KEV listing. |
|---|---|
| KEV status | Not listed in CISA KEV as of this assessment. |
| EPSS | 0.00068 from supplied intel; that is extremely low predicted exploitation probability. Percentile was not provided in the prompt. |
| Proof-of-concept availability | No public PoC located in quick triage. Expect Chromium bug details to remain restricted until patch adoption improves. |
| CVSS vector reality check | CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H captures potential impact, but it does not model the advisory's critical real-world precondition: attacker already owns the renderer. |
| Affected versions | Google Chrome on Windows prior to 149.0.7827.53 per supplied intel and the Chrome 149 rollout material. |
| Fixed version | 149.0.7827.53 or later on Windows. |
| Exposure population | Chrome is widely deployed, but this is a client-side browser flaw, so Shodan/Censys-style internet exposure counts are not meaningful here. |
| Timeline nuance | Chrome 149 stable release date was June 2, 2026; the user-supplied disclosure date is June 4, 2026. Treat that as likely CVE publication timing vs patch rollout timing. |
| Why this matters operationally | This is a sandbox-escape helper. Prioritize it higher only when paired with active renderer exploitation or a same-cycle renderer 0-day. |
noisgate verdict.
The single biggest severity reducer is the advisory's own precondition: the attacker must already have compromised the renderer process. That makes this a second-stage exploit-chain component, not a standalone internet-scale browser takeover bug, despite the high theoretical impact after compromise.
Why this verdict
- Major downward adjustment: requires prior renderer compromise — attacker position is not unauthenticated remote in practice; it implies a separate working browser exploit already exists.
- Exposure is broad but reachable population is narrow — Chrome is everywhere, but only systems where an attacker can first win the renderer and then land this exact version-specific second-stage bug are in scope.
- Telemetry says quiet, not hot — no KEV listing, very low EPSS, and no public exploitation notice from the release material keep this out of emergency lane.
Why not higher?
A higher rating would require a cleaner attack surface: standalone remote exploitability, active exploitation, or evidence that this reliably defeats the sandbox at scale. None of that is present in the supplied intel. The need for a preceding renderer compromise is compounding friction, not a minor caveat.
Why not lower?
It is still a memory-corruption bug in Chrome on Windows with potential sandbox-escape value once chained. In a browser exploit chain, second-stage bugs matter a lot, and the affected product is ubiquitous. That keeps it above LOW even without exploitation evidence.
What to do — in priority order.
- Keep Chrome auto-update enforced — Use enterprise policy to prevent stale browser builds from lingering. For a MEDIUM verdict there is no noisgate mitigation SLA; fold this into normal browser governance and complete patching inside the 365-day remediation window, preferably in the next routine browser wave rather than waiting for long-tail cleanup.
- Verify sandbox protections stay enabled — Audit for
--no-sandbox, debugging exceptions, or unsupported wrapper tooling that weakens Chrome's containment model. There is no mitigation SLA for MEDIUM, but this hardening should be maintained continuously because it specifically raises attacker friction for renderer-to-broker pivots. - Maintain Site Isolation defaults — Do not relax Chrome Site Isolation on managed Windows endpoints. It does not fix the bug, but it limits what a compromised renderer can reach and should remain enforced as standard hardening while remediation proceeds within the 365-day window.
- Hunt for Chrome crash clusters — Query EDR and reliability telemetry for repeated
chrome.execrashes, exploit prevention events, or suspicious relaunch loops on outdated builds. For MEDIUM, use this as targeted validation during the standard remediation cycle rather than as an emergency mitigation program.
- A WAF does not help; this is a client-side browser memory bug, not a server-side HTTP parsing issue you can shield upstream.
- Email/web filtering alone is insufficient; it may reduce delivery of malicious links, but it does nothing once the user reaches attacker-controlled browser content through another route.
- Version-only vulnerability scanning finds stale Chrome, but it will not tell you whether the exploit chain is actually being attempted or whether sandbox defenses interrupted it.
Crowdsourced verification payload.
Run this on the target Windows endpoint or through your remote management tool as a standard user; admin is not required. Example: powershell.exe -ExecutionPolicy Bypass -File .\check-chrome-cve-2026-10933.ps1 — it checks installed chrome.exe versions and returns VULNERABLE, PATCHED, or UNKNOWN.
# check-chrome-cve-2026-10933.ps1
# Verifies whether Google Chrome on Windows is older than 149.0.7827.53
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
param(
[string]$MinimumVersion = '149.0.7827.53'
)
function Get-ChromePaths {
$paths = New-Object System.Collections.Generic.List[string]
$candidates = @(
"$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 $candidates) {
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) {
try {
$item = Get-ItemProperty -Path $key -ErrorAction Stop
if ($item.'(default)' -and (Test-Path $item.'(default)')) {
[void]$paths.Add($item.'(default)')
}
if ($item.Path) {
$joined = Join-Path $item.Path 'chrome.exe'
if (Test-Path $joined) { [void]$paths.Add($joined) }
}
} catch {}
}
return $paths | Sort-Object -Unique
}
function Get-FileVersionSafe([string]$Path) {
try {
$item = Get-Item $Path -ErrorAction Stop
$ver = $item.VersionInfo.ProductVersion
if (-not $ver) { $ver = $item.VersionInfo.FileVersion }
if (-not $ver) { return $null }
$ver = ($ver -split '\s+')[0]
return [version]$ver
} catch {
return $null
}
}
try {
$min = [version]$MinimumVersion
} catch {
Write-Output 'UNKNOWN: invalid minimum version format.'
exit 2
}
$chromePaths = Get-ChromePaths
if (-not $chromePaths -or $chromePaths.Count -eq 0) {
Write-Output 'UNKNOWN: chrome.exe not found in standard install locations.'
exit 2
}
$results = @()
foreach ($path in $chromePaths) {
$ver = Get-FileVersionSafe -Path $path
if ($null -eq $ver) {
$results += [pscustomobject]@{ Path = $path; Version = $null; State = 'UNKNOWN' }
} elseif ($ver -lt $min) {
$results += [pscustomobject]@{ Path = $path; Version = $ver.ToString(); State = 'VULNERABLE' }
} else {
$results += [pscustomobject]@{ Path = $path; Version = $ver.ToString(); State = 'PATCHED' }
}
}
$results | ForEach-Object {
if ($_.Version) {
Write-Output ("{0} | {1} | {2}" -f $_.State, $_.Version, $_.Path)
} else {
Write-Output ("{0} | unknown-version | {1}" -f $_.State, $_.Path)
}
}
if ($results.State -contains 'VULNERABLE') {
Write-Output 'VULNERABLE'
exit 1
}
if (($results | Where-Object { $_.State -eq 'PATCHED' }).Count -gt 0 -and -not ($results.State -contains 'UNKNOWN')) {
Write-Output 'PATCHED'
exit 0
}
if (($results | Where-Object { $_.State -eq 'PATCHED' }).Count -gt 0 -and -not ($results.State -contains 'VULNERABLE')) {
Write-Output 'PATCHED'
exit 0
}
Write-Output 'UNKNOWN'
exit 2
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.