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

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

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

This is a burglar getting into the building lobby, not the vault

CVE-2026-11060 is a use-after-free bug in Chrome's Media component on Windows, affecting versions prior to 149.0.7827.53. A remote attacker can deliver a crafted HTML page that corrupts memory and execute code inside Chrome's renderer sandbox when a user loads the page. The vulnerable population is broad because the trigger is just web content, but the impact stated in the record is explicitly sandbox-scoped rather than immediate OS-level takeover.

The vendor-style 8.8/HIGH CVSS overstates what defenders actually need to fear from this bug *by itself*. In practice, this is a stage-one browser exploit: easy delivery, huge endpoint exposure, but materially constrained by user interaction and the fact that successful code execution lands inside the sandbox, which usually means an attacker still needs a second bug, a browser data theft path, or abuse of the logged-in session to turn it into full workstation compromise.

"High priority because Chrome is everywhere; not critical because this is renderer-sandbox RCE, not proven host compromise"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on attacker-controlled web content

The weaponized tool here is a crafted HTML page with malicious media logic delivered by phishing, malvertising, SEO poisoning, or compromised sites. No authentication or internal foothold is needed; the attacker just needs a Windows user running vulnerable Chrome to render the content.
Conditions required:
  • Victim uses Google Chrome on Windows below 149.0.7827.53
  • Victim loads attacker-controlled or attacker-influenced web content
  • Outbound web access is available
Where this breaks in practice:
  • Email security, web filtering, Safe Browsing, ad blocking, and user behavior reduce reach
  • This is UI:R; no page render, no exploit path
  • Some enterprises heavily broker or isolate risky browsing
Detection/coverage: Traditional vuln scanners have poor coverage for client-side triggerability. Detection is mostly indirect: web proxy logs, Safe Browsing hits, and browser crash telemetry.
STEP 02

Trigger the Media use-after-free

The exploit must drive Chrome's Media code into a freed-object reuse condition and then reclaim memory with attacker-controlled data. That is normal browser-exploitation work, but it still requires a reliable heap strategy for the exact Windows Chrome build and mitigations in play.
Conditions required:
  • A working exploit primitive for this specific bug and branch
  • Vulnerable media code path reachable from the rendered content
  • Target build behavior matches the exploit's heap assumptions
Where this breaks in practice:
  • Exploit reliability degrades across builds, feature flags, and heap state
  • Modern browser hardening, CFG, ASLR, and process isolation raise development cost
  • No public primary-source PoC was found in the reviewed material
Detection/coverage: Likely invisible to network scanners. Browser crash spikes, abnormal renderer exits, and exploit-behavior telemetry from EDR may provide weak signals.
STEP 03

Execute code inside the renderer sandbox

If the memory corruption lands, the attacker gets arbitrary code execution in the sandboxed renderer process. That can still be useful for session theft, in-browser actions, or staging a second exploit, but it is not the same thing as native code execution on the host with user or SYSTEM rights.
Conditions required:
  • Successful exploitation of the UAF
  • Payload compatible with Chrome renderer constraints
Where this breaks in practice:
  • The sandbox is the biggest real-world brake on severity
  • No OS-level privilege gain is inherent in this CVE alone
  • Post-exploitation options are narrower than the CVSS 8.8 headline implies
Detection/coverage: EDR may catch suspicious renderer memory behavior or anomalous child-process activity, but pure in-renderer abuse can be noisy only in browser telemetry.
STEP 04

Chain to real endpoint impact

To turn this into a true workstation-compromise event, the attacker usually needs a second-stage technique: sandbox escape, broker abuse, token/session theft, or another local privilege escalation path. That extra prerequisite is why this bug is dangerous but not top-of-stack critical on its own.
Conditions required:
  • A second vulnerability or a viable in-browser theft objective
  • Target stores useful browser-accessible secrets or privileged sessions
Where this breaks in practice:
  • No KEV listing and no reviewed evidence of a public exploit chain for this CVE
  • MFA, conditional access, and EDR limit payoff from browser-only execution
  • A separate escape bug is a major additional requirement
Detection/coverage: This is where defenders usually catch the actor: token abuse, new persistence, suspicious child processes, or lateral movement telemetry.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence reviewed of active exploitation; not listed in CISA KEV as of 2026-06-05.
Public PoC availabilityNo public PoC found in primary-source review. Assume exploit development, if any, is private/custom.
EPSS0.0008 (~0.08%), which is very low for near-term exploitation probability.
KEV statusNo. No KEV add date, no KEV due date.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — formula says remote code execution, but UI:R and sandbox confinement are the practical brakes.
Affected versionsGoogle Chrome on Windows versions before 149.0.7827.53.
Fixed versionUpgrade Windows Chrome to 149.0.7827.53 or later. The related early stable train published 149.0.7827.53/.54 for Windows/Mac, but this CVE is Windows-specific.
Exposure realityShodan/Censys/FOFA are poor indicators here because this is a client-side browser bug, not an internet-facing service. The exposure multiplier is endpoint population, and Chrome held roughly 71.56% worldwide desktop browser share in April 2026.
Disclosure date2026-06-04.
Researcher / reporterNo public reporter attribution was identified in the reviewed material. Chrome advisories often keep bug details restricted until rollout saturation improves.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (7.4/10)

The decisive factor is that this CVE delivers code execution inside Chrome's sandbox, which sharply reduces standalone blast radius versus a true host-level browser RCE. It stays HIGH because Chrome is ubiquitous and the attacker only needs to get a vulnerable Windows user to render web content—no creds, no LAN position, no prior foothold.

HIGH No known active exploitation / no KEV listing
MEDIUM Final severity bucket after factoring sandbox confinement against Chrome's exposure footprint

Why this verdict

  • Downshift for sandbox confinement: the public description says execution is inside a sandbox, so the vendor's 8.8 does not equal immediate endpoint takeover.
  • Downshift for user interaction: this is UI:R; the attacker needs the victim to load hostile content, which removes wormability and cuts reachable population.
  • Counterweight for exposure: Chrome is massively deployed, and the attacker position is still just unauthenticated remote web content, so this remains operationally important even without a second bug.
  • Downshift for threat intel: EPSS is only 0.0008, there is no KEV listing, and no public exploitation evidence was found in the reviewed material.
  • Vendor/CNA mismatch matters: downstream scoring treats the memory corruption like generic RCE, but Chrome's own ecosystem has a pattern of rating many sandboxed renderer bugs lower than the headline CVSS implies.

Why not higher?

This is not a confirmed sandbox escape, privilege escalation, or pre-auth service RCE against an enterprise server. The attacker still has to win a browser exploit and then do something useful from inside the renderer sandbox, which is a meaningful extra stage.

Why not lower?

Do not overcorrect just because it is sandboxed. Chrome's deployment footprint is enormous, the trigger is ordinary web content, and browser bugs are one of the most reusable initial-access primitives when attackers are willing to chain them.

05 · Compensating Control

What to do — in priority order.

  1. Force browser auto-update — Use enterprise policy or endpoint management to ensure Chrome updates are not deferred indefinitely and that relaunch enforcement is enabled for stale sessions. For a HIGH verdict, deploy this control within 30 days.
  2. Reduce risky browsing paths — Push high-risk users through browser isolation, remote browsing, or stricter web filtering categories for malvertising, newly registered domains, and uncategorized content. This lowers exploit delivery success and should be in place within 30 days.
  3. Watch for browser crash outliers — Collect Chrome crash telemetry and EDR signals for repeated renderer crashes, suspicious chrome.exe child processes, and abnormal module loads. This will not stop exploitation by itself, but it improves detection while remediation completes within 30 days.
  4. Harden session abuse paths — Enforce MFA, conditional access, and short session lifetimes for high-value SaaS so browser-only code execution is less profitable. Treat this as compensating friction to be rolled out within 30 days.
What doesn't work
  • Perimeter vuln scanning doesn't help much because this is a client-side browser flaw, not a listening service.
  • Antivirus signature reliance is weak here; memory-corruption browser exploits are usually behavior-driven and often custom-built.
  • Network segmentation is mostly irrelevant to the initial trigger because the attack arrives through normal outbound web browsing.
06 · Verification

Crowdsourced verification payload.

Run this on the target Windows endpoint or through your EDR/management agent. Invoke it with powershell -ExecutionPolicy Bypass -File .\Test-Chrome-CVE-2026-11060.ps1; standard user rights are usually enough for machine installs, but admin/SYSTEM is better if you want visibility into all user-profile installs.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# Test-Chrome-CVE-2026-11060.ps1
# Checks installed Google Chrome versions on Windows against fixed version 149.0.7827.53
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

param()

$ErrorActionPreference = 'SilentlyContinue'
$FixedVersion = [version]'149.0.7827.53'
$found = @()

function Add-Result {
    param(
        [string]$Path,
        [string]$Version,
        [string]$Source
    )
    if (-not [string]::IsNullOrWhiteSpace($Version)) {
        try {
            $obj = [PSCustomObject]@{
                Path    = $Path
                Version = [version]$Version
                Source  = $Source
            }
            $script:found += $obj
        } catch {
            # ignore unparsable versions
        }
    }
}

# Common executable paths
$exePaths = @(
    "$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
    "$env:ProgramFiles(x86)\Google\Chrome\Application\chrome.exe",
    "$env:LOCALAPPDATA\Google\Chrome\Application\chrome.exe"
) | Select-Object -Unique

foreach ($p in $exePaths) {
    if (Test-Path $p) {
        $ver = (Get-Item $p).VersionInfo.ProductVersion
        Add-Result -Path $p -Version $ver -Source 'FileVersion'
    }
}

# Registry uninstall keys
$regPaths = @(
    'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
    'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*',
    'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*'
)

foreach ($rp in $regPaths) {
    Get-ItemProperty $rp | Where-Object {
        $_.DisplayName -match 'Google Chrome'
    } | ForEach-Object {
        Add-Result -Path ($_.InstallLocation) -Version ($_.DisplayVersion) -Source 'Registry'
    }
}

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

$unique = $found | Sort-Object Version -Descending -Unique
$minVersion = ($unique | Sort-Object Version | Select-Object -First 1).Version

Write-Output 'Detected Chrome installations:'
$unique | ForEach-Object {
    Write-Output (" - Version {0} via {1} [{2}]" -f $_.Version, $_.Source, $_.Path)
}

if ($minVersion -lt $FixedVersion) {
    Write-Output ("VULNERABLE: At least one installed Chrome version is older than fixed version {0}." -f $FixedVersion)
    exit 1
} else {
    Write-Output ("PATCHED: All detected Chrome versions are >= {0}." -f $FixedVersion)
    exit 0
}
07 · Bottom Line

If you remember one thing.

TL;DR
On Monday morning, treat this as a HIGH-priority browser update, not a red-alert endpoint takeover. By 2026-07-05, meet the noisgate mitigation SLA by enforcing Chrome auto-update/relaunch policy and tightening risky browsing controls for exposed users; by 2026-12-02, meet the noisgate remediation SLA by verifying all Windows Chrome instances are on 149.0.7827.53+. In practice, because Chrome is easy to patch and broadly exposed, you should fold it into the current browser patch cycle, not leave it to the back half of that window.

Sources

  1. Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
  2. Chrome Help - Update Google Chrome
  3. CISA Known Exploited Vulnerabilities Catalog
  4. FIRST EPSS API
  5. FIRST EPSS overview
  6. StatCounter Desktop Browser Market Share Worldwide
  7. CVE Record
  8. NVD detail
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.