This is a burglar getting into the lobby, not the vault
CVE-2026-10913 is a CWE-416 use-after-free in Chrome's ANGLE graphics layer on Windows, affecting Google Chrome versions before 149.0.7827.53. A remote attacker can deliver a crafted web page that triggers memory corruption and gains code execution, but the user-supplied title says that execution lands inside a sandbox, not at OS level.
paragraph 2: Google's 8.8/HIGH baseline is fair in a vacuum because it's a browser memory-safety bug reachable from the web with no auth, but it overstates enterprise urgency for *this CVE standing alone*. The decisive friction is that the achieved code runs in Chrome's constrained renderer/GPU isolation model on Windows, so this is not the same as full workstation takeover unless an attacker also has a sandbox escape or privilege-escalation chain.
4 steps from start to impact.
Deliver a malicious page
- Target is running Chrome on Windows before
149.0.7827.53 - Victim visits attacker-controlled or attacker-influenced web content
- ANGLE code path is reachable in the target's browser session
- Requires user interaction (
UI:R), so this is not wormable - Enterprise web filtering, Safe Browsing, ad blocking, and URL isolation can break delivery before exploit execution
- Browser channel diversity and auto-update reduce long-tail exposure
Trigger ANGLE memory corruption
- The vulnerable code path is exercised successfully
- Exploit is stable enough for the victim's Chrome/Windows build combination
- Modern browser hardening makes reliability non-trivial even when the bug is reachable
- Driver variance and graphics stack differences can make exploit portability messy
- No public PoC or active-exploitation evidence was found in the sources reviewed
Land code execution in the sandbox
- The exploit achieves control flow
- The compromised process remains inside the renderer/GPU sandbox boundary
- Sandbox restrictions sharply limit filesystem, OS object, and direct system access
- Impact is bounded unless paired with another vulnerability or misconfiguration
- Blast radius is usually the current user session and browser context, not domain-wide compromise
Chain to full compromise if available
- Attacker has a viable follow-on exploit or environmental weakness
- Endpoint defenses fail to interrupt post-exploitation
- Second-stage chaining is the biggest real-world barrier
- EDR, exploit protection, browser isolation, and application control often catch or constrain this phase
- No evidence reviewed shows this CVE already packaged into active chains
The supporting signals.
| In-the-wild status | No confirmed active exploitation found in the reviewed sources, and the CVE is not KEV-listed. |
|---|---|
| Public exploit / PoC | No public PoC located in the sources reviewed. That lowers immediate weaponization pressure compared with recent Chrome zero-days. |
| EPSS | 0.0008 from the prompt, which is extremely low as a raw near-term exploitation probability. Percentile was not supplied in the prompt. |
| KEV status | Not listed in CISA KEV as of this assessment. |
| CVSS vector readout | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H means remote, no auth, but user interaction is required. The vendor vector also does not capture the practical downgrade from code exec inside the Chrome sandbox. |
| Affected versions | Google Chrome on Windows before 149.0.7827.53 per the user-supplied intel. |
| Fixed versions | Patch line is 149.0.7827.53 on Windows. Google's early stable note says Windows/Mac moved to 149.0.7827.53/.54, with Linux on 149.0.7827.53. |
| Exposure reality | This is a client-side browser bug, not an internet-facing service. Shodan/Censys/FOFA-style enumeration is not meaningful here; your exposure lives on endpoints and VDI images, not on port scans. |
| Disclosure timeline | The prompt gives 2026-06-04 as disclosure. Public update activity around this train also appears on May 29, 2026 (early stable release) and June 3, 2026 (government advisory), so treat this as an early-June 2026 patch event. |
| Researcher / reporting | Not identified in the sources reviewed. Chrome advisories in this window did not expose enough detail to attribute a finder from the pages accessed. |
noisgate verdict.
The single biggest downgrade factor is that the described end state is arbitrary code execution inside Chrome's sandbox, not host-level code execution. For an enterprise patch queue, that means this CVE is dangerous but usually needs a second-stage escape or local privilege escalation before it becomes a true workstation-compromise event.
Why this verdict
- Start from vendor 8.8/HIGH: network-reachable browser memory corruption with no privileges is always worth attention
- Downgrade for user interaction: the victim must browse to attacker content, which immediately narrows reachable population and gives web controls chances to stop delivery
- Downgrade again for sandboxed impact: the prompt's own description says code execution occurs *inside a sandbox*, which is a major practical brake on blast radius
- Downgrade for no exploitation signal: no KEV listing, no active-campaign evidence, and a very low EPSS remove the 'drop everything' pressure
- Hold at MEDIUM, not LOW, because Chrome is ubiquitous: a browser memory bug at fleet scale still matters, especially on unmanaged laptops, high-risk user groups, and internet-heavy roles
Why not higher?
If this were a confirmed sandbox escape, broker compromise, or a Chrome zero-day with active in-the-wild exploitation, it would jump fast. The available facts instead describe a single-stage browser bug whose achieved code execution remains contained by Chrome's Windows sandbox boundary.
Why not lower?
This is still a remotely delivered memory-safety flaw in one of the most widely deployed enterprise applications. At scale, even a sandboxed browser exploit can expose live session material, target high-value users, or serve as the first half of a chained intrusion.
What to do — in priority order.
- Force rapid browser auto-update — Make sure Chrome enterprise policy is enforcing background updates and relaunch prompts so endpoints move off vulnerable builds without waiting for user behavior. For a MEDIUM verdict there is no mitigation SLA; use this as a hardening measure while you complete patching inside the 365-day remediation window.
- Tighten risky web delivery paths — Reduce exploit delivery by hardening URL filtering, blocking newly registered domains where practical, and keeping browser Safe Browsing and anti-phishing controls fully enabled. There is no mitigation SLA for MEDIUM, but these controls are worth validating during the same remediation window because they cut exposure immediately.
- Prioritize high-risk user rings — Patch first on administrator workstations, executives, researchers, help desk jump boxes, and users who browse untrusted content heavily. This is how you get real risk reduction fast even when the vuln itself does not justify an emergency fleet-wide outage.
- Watch for crash and exploit telemetry — Correlate Chrome renderer/GPU crashes, exploit-guard events, and suspicious browser-child behavior in EDR. For a MEDIUM issue this is not a substitute for updating, but it gives you early signal if somebody is trying to operationalize the bug against your users.
Perimeter vulnerability scanningdoes not help much because Chrome on endpoints is not an internet-facing service you can enumerate remotelyMFAis valuable generally but does nothing to stop the memory corruption itself once a user opens the malicious pageNetwork segmentationis not the primary control here because the initial attack rides normal outbound web browsing
Crowdsourced verification payload.
Run this on the target Windows endpoint or through your EDR/management tool under a standard user context; admin is not required. Invoke with powershell -ExecutionPolicy Bypass -File .\check-chrome-cve-2026-10913.ps1 and it will inspect common Chrome install locations and report VULNERABLE, PATCHED, or UNKNOWN against the Windows fixed version 149.0.7827.53.
# check-chrome-cve-2026-10913.ps1
# Purpose: Determine whether Google Chrome on Windows is vulnerable to CVE-2026-10913
# Logic: Versions earlier than 149.0.7827.53 are VULNERABLE
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN
$ErrorActionPreference = 'SilentlyContinue'
$fixedVersion = [version]'149.0.7827.53'
function Get-ChromeCandidates {
$paths = @(
"$Env:ProgramFiles\Google\Chrome\Application\chrome.exe",
"$Env:ProgramFiles(x86)\Google\Chrome\Application\chrome.exe",
"$Env:LocalAppData\Google\Chrome\Application\chrome.exe"
)
$regPaths = @(
'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 ($rp in $regPaths) {
$reg = Get-ItemProperty -Path $rp
if ($reg -and $reg.'(default)') {
$paths += $reg.'(default)'
}
elseif ($reg -and $reg.Path) {
$paths += (Join-Path $reg.Path 'chrome.exe')
}
}
$paths | Where-Object { $_ -and (Test-Path $_) } | Select-Object -Unique
}
function Get-FileVersionString($path) {
try {
return (Get-Item $path).VersionInfo.ProductVersion
}
catch {
return $null
}
}
$candidates = Get-ChromeCandidates
if (-not $candidates -or $candidates.Count -eq 0) {
Write-Output 'UNKNOWN: Google Chrome not found in standard locations.'
exit 2
}
$results = @()
foreach ($chromePath in $candidates) {
$verString = Get-FileVersionString $chromePath
if (-not $verString) {
$results += [pscustomobject]@{
Path = $chromePath
Version = $null
State = 'UNKNOWN'
}
continue
}
try {
$ver = [version]$verString
$state = if ($ver -lt $fixedVersion) { 'VULNERABLE' } else { 'PATCHED' }
}
catch {
$state = 'UNKNOWN'
}
$results += [pscustomobject]@{
Path = $chromePath
Version = $verString
State = $state
}
}
$results | ForEach-Object {
Write-Output ("{0}: {1} ({2})" -f $_.State, $_.Path, ($_.Version ? $_.Version : 'version unreadable'))
}
if ($results.State -contains 'VULNERABLE') {
exit 1
}
elseif ($results.State -contains 'PATCHED') {
exit 0
}
else {
exit 2
}
If you remember one thing.
149.0.7827.53 into your normal browser update wave, and front-load high-risk user groups first. Because this is MEDIUM, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; the noisgate remediation SLA is therefore patch within 365 days. If your org already has fast Chrome auto-update, the practical move is simple: validate coverage, chase exceptions, and close the stragglers rather than launching an emergency change.Sources
- Chrome Releases: Early Stable Update for Desktop (149.0.7827.53/.54)
- Canadian Centre for Cyber Security advisory AV26-544
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS overview
- FIRST EPSS data/API documentation
- Chromium multi-process architecture
- Chrome sandbox diagnostics for Windows
- Chromium GPU accelerated compositing and GPU process design
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.