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

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

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

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.

"This is a second-stage Chrome sandbox escape, not a clean unauth RCE. Patch it, but don't let the 8.3 score bully your queue."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land code execution in a renderer

The attacker first needs a separate browser bug that yields renderer compromise from attacker-controlled content, typically via a malicious page using custom HTML/JS and a memory-corruption primitive. This CVE does not provide that initial foothold; it only becomes relevant once arbitrary code already runs inside Chrome's sandboxed renderer.
Conditions required:
  • Victim uses affected Chrome on Windows
  • Attacker can get the user to load hostile content
  • Attacker has a separate working renderer exploit
Where this breaks in practice:
  • 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
Detection/coverage: Network and vuln scanners will not see step 1 directly. Detection is mostly via browser crash telemetry, EDR exploit alerts, and forensic signs of renderer instability.
STEP 02

Trigger the Audio UAF from the compromised renderer

With code already running in the renderer, the attacker uses Chrome's exposed browser/runtime surfaces to drive the vulnerable Audio path and hit the use-after-free condition. In practice this is a post-exploitation pivot from a low-privilege renderer toward a more privileged process or service boundary.
Conditions required:
  • Renderer is already compromised
  • Target build is below 149.0.7827.53
  • The exploit chain can reliably reach the affected Audio code path
Where this breaks in practice:
  • 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
Detection/coverage: Exploit-specific coverage is poor. At best, EDR may surface abnormal browser memory corruption or repeated Chrome crash/relaunch patterns.
STEP 03

Cross the sandbox boundary

If exploitation succeeds, the attacker can potentially convert renderer foothold into access beyond the renderer's heavy sandbox restrictions. On Windows, that matters because Chromium renderers run with a highly restricted token and rely on brokered IPC for privileged actions; defeating that boundary is where the value of this bug sits.
Conditions required:
  • A reliable exploit primitive is achieved from the Audio UAF
  • Chrome sandboxing is enabled normally
  • No hardening or platform behavior breaks the exploit chain
Where this breaks in practice:
  • 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
Detection/coverage: Direct detection is weak. Strongest signals are exploit prevention hits, unusual broker/renderer crash pairs, and endpoint telemetry showing abnormal browser process behavior.
STEP 04

Abuse the widened foothold

After escape, the attacker can pursue credential theft, local data access, or follow-on execution with the privileges available to the compromised Chrome context and user. Impact can be serious, but it is still chained impact, not a one-bug remote takeover story.
Conditions required:
  • Successful sandbox escape
  • Useful user context or reachable local assets
Where this breaks in practice:
  • Impact is bounded by user context and downstream controls
  • App isolation, EDR, and credential protections can still reduce blast radius
Detection/coverage: This is where detection improves: EDR, browser hardening telemetry, and suspicious-child-process analytics are more likely to catch follow-on behavior than the exploit itself.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo current public exploitation signal found in the vendor release material, and no CISA KEV listing.
KEV statusNot listed in CISA KEV as of this assessment.
EPSS0.00068 from supplied intel; that is extremely low predicted exploitation probability. Percentile was not provided in the prompt.
Proof-of-concept availabilityNo public PoC located in quick triage. Expect Chromium bug details to remain restricted until patch adoption improves.
CVSS vector reality checkCVSS: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 versionsGoogle Chrome on Windows prior to 149.0.7827.53 per supplied intel and the Chrome 149 rollout material.
Fixed version149.0.7827.53 or later on Windows.
Exposure populationChrome is widely deployed, but this is a client-side browser flaw, so Shodan/Censys-style internet exposure counts are not meaningful here.
Timeline nuanceChrome 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 operationallyThis is a sandbox-escape helper. Prioritize it higher only when paired with active renderer exploitation or a same-cycle renderer 0-day.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.9/10)

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.

HIGH Affected version boundary on Windows
HIGH Post-renderer-compromise prerequisite materially lowers urgency
MEDIUM No public exploitation or PoC signal at assessment time

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. Hunt for Chrome crash clusters — Query EDR and reliability telemetry for repeated chrome.exe crashes, 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.
What doesn't work
  • 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.
06 · Verification

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.

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

If you remember one thing.

TL;DR
Monday morning: treat this as a standard browser remediation item, not an emergency outage driver. There is no noisgate mitigation SLA — go straight to the 365-day remediation window for this MEDIUM verdict, but because Chrome is a fast-moving client platform, push affected Windows endpoints onto the current stable build in your next normal browser deployment cycle and verify auto-update policy is actually working; the noisgate remediation SLA is ≤365 days, and there is no evidence here that justifies breaking change-control within hours.

Sources

  1. Chrome Releases: Early Stable Update for Desktop (149.0.7827.53/.54)
  2. Chrome 149 release notes
  3. Chromium sandbox FAQ
  4. Chromium sandbox design for Windows
  5. Chromium Site Isolation overview
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS API documentation
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.