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
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
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. |
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
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.
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
}