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.
4 steps from start to impact.
Deliver a crafted page with an ANGLE trigger
- Victim must browse to attacker-controlled content
- Victim must be running Chrome on Windows
- Victim version must be older than
149.0.7827.53
- 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
Trigger the use-after-free in ANGLE
- A reachable vulnerable ANGLE path on the victim build
- Reliable heap shaping under that Chrome\/Windows build
- 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
chrome.exe crashes, GPU process instability, or Windows Error Reporting events, but routine vuln scanners generally do not validate exploitability here.Gain code execution inside Chrome's sandbox
- Successful exploit development beyond crash reproduction
- Sandbox is intact but the compromised process can still execute attacker logic
- 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
chrome.exe behavior, memory exploitation chains, unusual IPC patterns, or follow-on attempts to spawn child processes from the browser.Chain a second bug or settle for browser-scoped impact
- A second exploitable weakness or a separate post-exploitation path
- Defenses fail to stop the follow-on chain
- 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
The supporting signals.
| In-the-wild status | No 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 status | Not KEV-listed as of 2026-06-05; no CISA catalog entry was found for this CVE. |
| EPSS | 0.0008 from the user-supplied intel, which is extremely low and consistent with a fresh client-side bug that lacks public exploitation signals. |
| CVSS view | The 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 mismatch | Chrome'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 versions | Google'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 version | Patch floor for the affected platform is Google Chrome 149.0.7827.53 or later on Windows. |
| PoC availability | No 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 reality | This 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 reporter | The 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. |
noisgate verdict.
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.
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.
What to do — in priority order.
- 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.
- Hunt for abnormal Chrome child-process behavior — Tune EDR detections for
chrome.exespawning 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. - 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.
- 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.
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.
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
}
If you remember one thing.
Sources
- Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
- Chromium issue 498881735
- Chromium Security - Severity Guidelines for Security Issues
- Chromium Security
- Chrome sandbox diagnostics for Windows
- Chromium Memory Safety
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS API documentation
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.