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.
4 steps from start to impact.
Land the victim on attacker-controlled web content
- 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
- 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
Trigger the Media use-after-free
- 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
- 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
Execute code inside the renderer sandbox
- Successful exploitation of the UAF
- Payload compatible with Chrome renderer constraints
- 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
Chain to real endpoint impact
- A second vulnerability or a viable in-browser theft objective
- Target stores useful browser-accessible secrets or privileged sessions
- 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
The supporting signals.
| In-the-wild status | No public evidence reviewed of active exploitation; not listed in CISA KEV as of 2026-06-05. |
|---|---|
| Public PoC availability | No public PoC found in primary-source review. Assume exploit development, if any, is private/custom. |
| EPSS | 0.0008 (~0.08%), which is very low for near-term exploitation probability. |
| KEV status | No. No KEV add date, no KEV due date. |
| CVSS vector | CVSS: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 versions | Google Chrome on Windows versions before 149.0.7827.53. |
| Fixed version | Upgrade 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 reality | Shodan/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 date | 2026-06-04. |
| Researcher / reporter | No public reporter attribution was identified in the reviewed material. Chrome advisories often keep bug details restricted until rollout saturation improves. |
noisgate verdict.
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.
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.
What to do — in priority order.
- 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.
- 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.
- Watch for browser crash outliers — Collect Chrome crash telemetry and EDR signals for repeated renderer crashes, suspicious
chrome.exechild processes, and abnormal module loads. This will not stop exploitation by itself, but it improves detection while remediation completes within 30 days. - 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.
- 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.
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.
# 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
}
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.