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

Use after free in ANGLE 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 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.

"Serious browser memory bug, but the sandbox keeps this out of emergency-patching territory by itself"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a malicious page

The attacker hosts or injects a page that exercises the vulnerable ANGLE code path using crafted HTML/JavaScript and graphics content. In practice this is standard browser exploit delivery: phishing, malvertising, compromised sites, or watering holes. No authentication is needed, but the victim must browse to attacker-controlled content.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Standard network scanners will not find this; exposure is endpoint state plus browsing activity. Secure web gateways, browser telemetry, and crash analytics are more useful than perimeter vuln scanning.
STEP 02

Trigger ANGLE memory corruption

The crafted page drives a use-after-free in ANGLE, likely through a graphics or GPU-adjacent rendering path. A weaponized exploit would need to convert that bug into reliable corruption and instruction control under current Chrome and Windows mitigations.
Conditions required:
  • The vulnerable code path is exercised successfully
  • Exploit is stable enough for the victim's Chrome/Windows build combination
Where this breaks in practice:
  • 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
Detection/coverage: Likely manifests as renderer/GPU crashes, browser instability, or exploit-guard/EDR signals rather than clean signature-based detection. Coverage is strongest in EDR crash correlation and browser enterprise reporting.
STEP 03

Land code execution in the sandbox

Successful exploitation yields arbitrary code execution inside Chrome's sandboxed process context, not automatic escape to the host. That still gives the attacker a foothold in the browser security boundary and can expose page data, active sessions, or become one half of a later exploit chain.
Conditions required:
  • The exploit achieves control flow
  • The compromised process remains inside the renderer/GPU sandbox boundary
Where this breaks in practice:
  • 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
Detection/coverage: EDR may see anomalous child-process behavior, exploit mitigations, or memory-corruption artifacts. Browser-side detections and Windows mitigations are more relevant than traditional vuln checks.
STEP 04

Chain to full compromise if available

To turn this into workstation takeover, the attacker typically needs a second bug such as a sandbox escape, GPU-process breakout, broker flaw, or local privilege escalation. Without that second stage, the standalone security outcome is materially less severe than a classic no-sandbox browser RCE.
Conditions required:
  • Attacker has a viable follow-on exploit or environmental weakness
  • Endpoint defenses fail to interrupt post-exploitation
Where this breaks in practice:
  • 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
Detection/coverage: This is where EDR has the best chance: sandbox escape attempts, abnormal broker access, token abuse, or suspicious process creation are the high-signal events.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed active exploitation found in the reviewed sources, and the CVE is not KEV-listed.
Public exploit / PoCNo public PoC located in the sources reviewed. That lowers immediate weaponization pressure compared with recent Chrome zero-days.
EPSS0.0008 from the prompt, which is extremely low as a raw near-term exploitation probability. Percentile was not supplied in the prompt.
KEV statusNot listed in CISA KEV as of this assessment.
CVSS vector readoutCVSS: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 versionsGoogle Chrome on Windows before 149.0.7827.53 per the user-supplied intel.
Fixed versionsPatch 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 realityThis 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 timelineThe 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 / reportingNot identified in the sources reviewed. Chrome advisories in this window did not expose enough detail to attribute a finder from the pages accessed.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.3/10)

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.

MEDIUM Reassessed severity
HIGH Affected version boundary on Windows
MEDIUM No active-exploitation / no-KEV judgment

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • Perimeter vulnerability scanning does not help much because Chrome on endpoints is not an internet-facing service you can enumerate remotely
  • MFA is valuable generally but does nothing to stop the memory corruption itself once a user opens the malicious page
  • Network segmentation is not the primary control here because the initial attack rides normal outbound web browsing
06 · Verification

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.

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

If you remember one thing.

TL;DR
Monday morning: treat this as a browser-fleet hygiene issue, not a SEV-1. Query all Windows endpoints for Chrome versions, move anything older than 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

  1. Chrome Releases: Early Stable Update for Desktop (149.0.7827.53/.54)
  2. Canadian Centre for Cyber Security advisory AV26-544
  3. CISA Known Exploited Vulnerabilities Catalog
  4. FIRST EPSS overview
  5. FIRST EPSS data/API documentation
  6. Chromium multi-process architecture
  7. Chrome sandbox diagnostics for Windows
  8. Chromium GPU accelerated compositing and GPU process design
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.