← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11055 · 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 apartment lobby, not the penthouse

CVE-2026-11055 is a use-after-free in Chrome's ANGLE graphics layer on Windows that affects versions prior to 149.0.7827.53. A malicious site can trigger memory corruption through normal browser content and potentially execute attacker-controlled code, but the execution context described for this CVE is inside a sandboxed Chrome process, not the full host.

The user's starting baseline of HIGH 8.8 overstates the operational risk for enterprise patch triage. In real deployments this is gated by user interaction, Windows-only scope, and most importantly sandbox confinement; without a second vulnerability or a local escape, this is usually a dead-end for full-host compromise, which is why Chrome's own release notes list this bug as Medium rather than a top-tier browser emergency.

"Drive-by reachable, but the bug lands inside Chrome's sandbox and stops there unless the attacker has a second move."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a crafted page with an ANGLE trigger

The attacker uses a malicious site, ad slot, or watering-hole page to drive victim Chrome on Windows into a code path that exercises ANGLE. The practical weapon is a custom HTML\/JavaScript\/graphics payload rather than a commodity exploit kit with public signatures.
Conditions required:
  • Victim must browse to attacker-controlled content
  • Victim must be running Chrome on Windows
  • Victim version must be older than 149.0.7827.53
Where this breaks in practice:
  • Requires UI:R; this is not a blind server-side hit
  • Windows-only narrows reachable population in mixed OS fleets
  • Public exploit code was not found in ordinary GitHub\/Exploit-DB searches at assessment time
Detection/coverage: Network scanners will not find this. Browser exploit delivery may show up only as suspicious child-process behavior, crash telemetry, or web filtering hits on known malicious domains.
STEP 02

Trigger the use-after-free in ANGLE

The page coerces ANGLE into dereferencing freed memory, creating a corruption primitive in a process handling graphics work. Depending on exploit quality, the attacker may move from crash to controlled instruction flow.
Conditions required:
  • A reachable vulnerable ANGLE path on the victim build
  • Reliable heap shaping under that Chrome\/Windows build
Where this breaks in practice:
  • Modern browser hardening, allocator behavior, and exploit reliability problems make many UAFs crash-only in practice
  • Google often restricts bug details until patch adoption improves, which slows copycat weaponization
Detection/coverage: Endpoint telemetry may record chrome.exe crashes, GPU process instability, or Windows Error Reporting events, but routine vuln scanners generally do not validate exploitability here.
STEP 03

Gain code execution inside Chrome's sandbox

If exploitation succeeds, the attacker gets code execution in the vulnerable sandboxed process, which is materially weaker than native code execution on the host. That lets them act as the compromised browser process, not as the full user or SYSTEM.
Conditions required:
  • Successful exploit development beyond crash reproduction
  • Sandbox is intact but the compromised process can still execute attacker logic
Where this breaks in practice:
  • This is the decisive limiter: the described impact is sandboxed code execution, not host escape
  • Chrome's site isolation and Windows sandboxing reduce what the process can touch directly
Detection/coverage: EDR can catch anomalous chrome.exe behavior, memory exploitation chains, unusual IPC patterns, or follow-on attempts to spawn child processes from the browser.
STEP 04

Chain a second bug or settle for browser-scoped impact

To turn this into a true workstation takeover, the attacker usually needs a second vulnerability for sandbox escape, broker abuse, token theft, or a separate local privilege escalation. Without that second stage, the blast radius is mostly limited to what the sandboxed process can access and whatever browser-resident data the attacker can still manipulate.
Conditions required:
  • A second exploitable weakness or a separate post-exploitation path
  • Defenses fail to stop the follow-on chain
Where this breaks in practice:
  • No evidence in the sourced material that CVE-2026-11055 ships with a paired sandbox escape
  • Most real enterprise EDR stacks are better at catching the noisy second stage than the initial memory bug
Detection/coverage: Look for browser-to-OS pivoting: suspicious child processes, token abuse, LOLBin launches, or crash-followed-by-execution sequences from Chrome.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo active exploitation evidence found in the sources reviewed; Chrome has a separate fast-track process for bugs with in-the-wild evidence, and this CVE was not presented that way in the release notes.
KEV statusNot KEV-listed as of 2026-06-05; no CISA catalog entry was found for this CVE.
EPSS0.0008 from the user-supplied intel, which is extremely low and consistent with a fresh client-side bug that lacks public exploitation signals.
CVSS viewThe supplied vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H scores it like a generic browser RCE, but that abstract score misses the operational reality that the code execution is inside the sandbox.
Vendor severity mismatchChrome's June 2, 2026 stable release notes list CVE-2026-11055 as Medium, which is materially lower than the user-supplied HIGH 8.8 baseline.
Affected versionsGoogle's desktop stable bulletin ties the fix set to Chrome 149.0.7827.53\/54 for Windows\/Mac and 149.0.7827.53 for Linux; this CVE specifically describes Windows prior to 149.0.7827.53.
Fixed versionPatch floor for the affected platform is Google Chrome 149.0.7827.53 or later on Windows.
PoC availabilityNo public PoC located in normal GitHub or Exploit-DB discovery during this assessment. That does not prove safety, but it does lower copycat risk compared with already-weaponized browser bugs.
Exposure and scanning realityThis is a desktop client vulnerability. Shodan\/Censys\/FOFA-style internet exposure counts are basically irrelevant here; your problem is endpoint version inventory, not perimeter scan surface.
Disclosure and reporterThe user supplied 2026-06-04 as disclosure date. Chrome's release notes show the underlying issue was reported by Google on 2026-04-02 under Chromium issue 498881735.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.8/10)

The single biggest reason this lands at MEDIUM is that successful exploitation gives the attacker code execution inside Chrome's sandbox, not on the host. That sharply reduces immediate blast radius and means a real workstation compromise usually needs a second bug or a separate post-exploitation path.

HIGH Affected version floor and Windows-only scope
HIGH Sandboxed-impact interpretation from Chromium severity guidance
MEDIUM Absence of public PoC or in-the-wild exploitation evidence

Why this verdict

  • Sandboxed-only impact cuts the score down hard: the CVE text itself says code execution occurs *inside a sandbox*, which is materially different from browser-process or host-level code execution.
  • User interaction is a real gate: the attacker needs a user to render malicious web content, so this is a drive-by risk, not an unauthenticated no-click server compromise.
  • Windows-only narrows the population: Mac, Linux, iOS, Android, and ChromeOS hosts are out-of-scope for this specific CVE, which matters when you are triaging a mixed 10,000-host estate.
  • Threat intel is quiet: no KEV entry, no public exploitation evidence in the reviewed sources, and a very low user-supplied EPSS all push downward from the abstract 8.8 baseline.

Why not higher?

It is not HIGH or CRITICAL in patch-priority terms because there is no sourced evidence here of sandbox escape, active exploitation, or a bundled exploit chain. A browser memory bug is serious, but a sandboxed foothold without a proven second-stage escape is not the same as immediate host compromise.

Why not lower?

It is not LOW or IGNORE because the trigger is still reachable by an unauthenticated remote attacker through ordinary web content, and Chrome is ubiquitous in enterprise fleets. Even sandboxed code execution can be useful for credential theft, browser-session abuse, or chaining with another weakness.

05 · Compensating Control

What to do — in priority order.

  1. Force Chrome auto-update on Windows — Make sure enterprise policy is not deferring stable browser updates longer than necessary. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but browser auto-update should be treated as baseline hygiene so vulnerable builds age out quickly.
  2. Hunt for abnormal Chrome child-process behavior — Tune EDR detections for chrome.exe spawning LOLBins, script hosts, installers, or other unusual descendants. This is the most practical compensating control while waiting for patch compliance because the second-stage pivot is usually louder than the initial memory corruption; for MEDIUM, there is no mitigation SLA — use this as hygiene control until patch completion.
  3. Reduce risky browsing exposure for high-value users — Apply stricter web filtering, remote browser isolation, or hardened browsing groups for admins, finance, and executives who face the most realistic watering-hole risk. This does not replace patching, but it lowers the chance that a crafted page ever reaches the vulnerable browser during the remediation window.
What doesn't work
  • Perimeter vulnerability scanners do not meaningfully detect this; browser patch state is an endpoint inventory problem, not a network-banner problem.
  • MFA does nothing to stop the memory corruption itself; it only helps with downstream account abuse if the attacker pivots to credential theft.
  • User awareness alone is weak here because a normal web page visit is enough; there is no reliable human tell for an ANGLE exploit page.
06 · Verification

Crowdsourced verification payload.

Run this on the target Windows host or through your endpoint management tool. Example: powershell -ExecutionPolicy Bypass -File .\check-chrome-cve-2026-11055.ps1 or powershell -ExecutionPolicy Bypass -File .\check-chrome-cve-2026-11055.ps1 -MinVersion 149.0.7827.53. Standard user rights are usually enough because the script reads registry and file version data only.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
param(
    [string]$MinVersion = "149.0.7827.53"
)

# check-chrome-cve-2026-11055.ps1
# Purpose: Detect whether Google Chrome on Windows is below the fixed version for CVE-2026-11055.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

function Get-ChromeVersionFromExe {
    param([string]$Path)
    try {
        if (Test-Path $Path) {
            $item = Get-Item $Path -ErrorAction Stop
            if ($item.VersionInfo -and $item.VersionInfo.ProductVersion) {
                return $item.VersionInfo.ProductVersion
            }
        }
    } catch {}
    return $null
}

function Get-ChromeVersionFromRegistry {
    $paths = @(
        '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 ($p in $paths) {
        try {
            $reg = Get-ItemProperty -Path $p -ErrorAction Stop
            if ($reg.'(default)') {
                $v = Get-ChromeVersionFromExe -Path $reg.'(default)'
                if ($v) { return $v }
            }
            if ($reg.Path) {
                $candidate = Join-Path $reg.Path 'chrome.exe'
                $v = Get-ChromeVersionFromExe -Path $candidate
                if ($v) { return $v }
            }
        } catch {}
    }
    return $null
}

function Normalize-Version {
    param([string]$VersionString)
    try {
        return [version]$VersionString
    } catch {
        return $null
    }
}

$candidatePaths = @(
    "$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
    "$env:ProgramFiles(x86)\Google\Chrome\Application\chrome.exe",
    "$env:LocalAppData\Google\Chrome\Application\chrome.exe"
)

$foundVersions = @()

foreach ($path in $candidatePaths) {
    $v = Get-ChromeVersionFromExe -Path $path
    if ($v) { $foundVersions += $v }
}

$regVersion = Get-ChromeVersionFromRegistry
if ($regVersion) { $foundVersions += $regVersion }

$foundVersions = $foundVersions | Sort-Object -Unique

if (-not $foundVersions -or $foundVersions.Count -eq 0) {
    Write-Output "UNKNOWN: Google Chrome not found or version unreadable"
    exit 2
}

$min = Normalize-Version -VersionString $MinVersion
if (-not $min) {
    Write-Output "UNKNOWN: Invalid minimum version supplied: $MinVersion"
    exit 2
}

$parsed = @()
foreach ($fv in $foundVersions) {
    $pv = Normalize-Version -VersionString $fv
    if ($pv) {
        $parsed += [pscustomobject]@{ Raw = $fv; Parsed = $pv }
    }
}

if (-not $parsed -or $parsed.Count -eq 0) {
    Write-Output "UNKNOWN: Found Chrome but could not parse any version values"
    exit 2
}

# If any discovered Chrome install is below the fixed version, flag host as vulnerable.
$vuln = $parsed | Where-Object { $_.Parsed -lt $min }

if ($vuln) {
    $versions = ($parsed.Raw -join ', ')
    Write-Output "VULNERABLE: Detected Chrome version(s): $versions ; fixed version is $MinVersion or later"
    exit 1
} else {
    $versions = ($parsed.Raw -join ', ')
    Write-Output "PATCHED: Detected Chrome version(s): $versions ; all meet or exceed $MinVersion"
    exit 0
}
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, pull an inventory of Windows Chrome endpoints below 149.0.7827.53 and fold them into your normal browser update motion rather than declaring an emergency outage. For this MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window; use the actual Chrome update as the remediation action and close the fleet to 149.0.7827.53+ within the noisgate remediation SLA of 365 days, preferably much sooner through your routine browser rollout because browsers age badly when left behind.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
  2. Chromium issue 498881735
  3. Chromium Security - Severity Guidelines for Security Issues
  4. Chromium Security
  5. Chrome sandbox diagnostics for Windows
  6. Chromium Memory Safety
  7. CISA Known Exploited Vulnerabilities Catalog
  8. FIRST EPSS API documentation
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.