This is the deadbolt bypass after the burglar is already inside the foyer
CVE-2026-11056 affects Google Chrome on Windows prior to 149.0.7827.53. The flaw sits in Site Isolation, and the key clause in the official description matters more than the scary CVSS math: the attacker must have already compromised the renderer process and then use a crafted HTML page to try to turn that foothold into a sandbox escape.
That makes the raw 9.6 label misleading for patch triage. Chromium's own security severity is Medium, while NVD's CISA-ADP overlay scores it 9.6 Critical; for defenders, the real-world story is a second-stage exploit primitive, not a one-click internet-to-host compromise. Wide browser deployment keeps it relevant, but the need for a separate renderer exploit is a massive downward pressure on urgency.
4 steps from start to impact.
Land the victim on attacker-controlled web content
- Target uses Chrome on Windows
- Version is below 149.0.7827.53
- User opens attacker-controlled content
- User interaction is required
- Email/web filtering and Safe Browsing can block the lure or payload host
- Enterprise browser isolation or VDI can break the path
Exploit a separate renderer bug first
- A reliable renderer compromise exists and works against the target build
- The page reaches the vulnerable renderer code path
- This is the biggest real-world brake: the CVE is not initial access
- Modern exploit mitigations and browser hardening reduce chain reliability
- Public exploit evidence for this CVE was not found
Abuse Site Isolation validation to cross the sandbox boundary
- Renderer process is already compromised
- Target is Windows
- Chrome is prior to 149.0.7827.53
- Windows-only scope cuts reachable population
- Site Isolation is a security boundary specifically built to contain compromised renderers
- The underlying Chromium issue is restricted, so exploit details are not broadly exposed
Execute post-escape actions on the endpoint
- Successful sandbox escape
- Follow-on payload or living-off-the-land action available
- Escape does not automatically mean SYSTEM or domain compromise
- EDR, ASR, WDAC/AppLocker, and user-context limits still matter
- Post-exploitation activity is noisier than pure browser memory corruption
chrome.exe, and unusual file/network actions.The supporting signals.
| In-the-wild status | No public evidence of active exploitation was found in the browsed sources, and it is not listed in CISA KEV. |
|---|---|
| Proof-of-concept availability | No public PoC or Metasploit-style weaponization was located. The referenced Chromium bug 498887785 is access-restricted. |
| EPSS | 0.00047 from the supplied intel — extremely low predicted near-term exploitation probability. Percentile was not verified from primary sources. |
| KEV status | Absent from the CISA Known Exploited Vulnerabilities Catalog as checked against the current catalog source. |
| CVSS vs reality | NVD shows CISA-ADP 9.6 / Critical with AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H, but the description itself says the attacker must have already compromised the renderer process. That prerequisite is not reflected well in the headline score. |
| Affected versions | Chrome on Windows prior to 149.0.7827.53. This is not described as a Linux/macOS issue. |
| Fixed version | Patched in 149.0.7827.53 for Windows. Google first shipped that build in the early stable rollout on 2026-05-29, then broader stable rollout began 2026-06-02. |
| Exposure population | Chrome is ubiquitous, which keeps the blast radius relevant. But this is a client-side local browser state issue, not an internet-facing service flaw. |
| Scanning / internet exposure data | Shodan/Censys-style internet scans are mostly irrelevant here; those platforms enumerate publicly reachable services, not endpoint browser versions. Use endpoint inventory, EDR, or software asset management instead. |
| Disclosure / reporter | Published 2026-06-04 in NVD. Public browsed sources do not name an external reporter; Chromium issue details are restricted. |
noisgate verdict.
The decisive factor is simple: this bug requires a prior renderer compromise, so it is not an initial-access browser RCE in the way the 9.6 label suggests. That makes it a meaningful chain component, but not an emergency standalone crisis across a 10,000-seat fleet.
Why this verdict
- Start at 9.6, then cut hard because this is post-renderer-compromise: the official description requires the attacker to have *already compromised the renderer process*, which implies a separate exploit stage before CVE-2026-11056 contributes anything.
- Windows-only scope narrows the reachable population: even in Chrome-heavy shops, this excludes non-Windows fleets and cuts down chain portability.
- No exploitation heat: not in KEV, no public PoC found, and the supplied EPSS of
0.00047is consistent with low short-term attacker interest. - Still not low: if you are already dealing with a browser chain, a sandbox escape is exactly the kind of primitive that turns a web compromise into an endpoint incident.
Why not higher?
Because this is not a one-bug remote compromise. It requires attacker-controlled content, user interaction, and—most importantly—a separate successful renderer compromise before the Site Isolation flaw becomes useful. That compounding friction is too much to justify HIGH or CRITICAL as a standalone patching emergency.
Why not lower?
Because the affected product is one of the most widely deployed user applications in the enterprise, and sandbox escapes are high-value chain amplifiers. If an attacker already has renderer execution, this bug can materially change the outcome from browser containment to host impact, so it does not belong in backlog hygiene.
What to do — in priority order.
- Enforce browser auto-update compliance — Use GPO, Chrome Enterprise policy, or your endpoint management stack to verify Windows endpoints are taking Chrome updates and are not pinned below
149.0.7827.53. For a MEDIUM verdict there is no mitigation SLA; focus on normalizing version drift and complete remediation within 365 days. - Prioritize high-risk browsing populations — Check developer workstations, privileged admin endpoints, research teams, and users with broad web access first, because a sandbox escape matters most where hostile content is common and credentials are valuable. There is no mitigation SLA for this bucket, but use this control immediately if patch lag exists while staying inside the 365-day remediation window.
- Harden browser-to-endpoint pivot paths — Keep EDR exploit prevention, Microsoft Defender ASR rules, WDAC/AppLocker, and least-privilege controls enforced so a successful browser sandbox escape still hits another wall. This does not replace patching, but it reduces the payoff of chained exploitation while you work through standard remediation.
- Monitor version laggards in endpoint inventory — Track Chrome version posture from EDR, SCCM/Intune, Tanium, BigFix, or equivalent instead of relying on network scanners. For this MEDIUM reassessment, there is no mitigation SLA — go straight to the 365-day remediation window and manage exceptions explicitly.
- Perimeter vulnerability scanning does not solve this, because the issue lives in a client browser and is not exposed as a remotely scannable listening service.
- A WAF does nothing here; the exploit path is in the user's local browser process, not your web application stack.
- MFA is valuable overall but irrelevant to the exploitability of the browser sandbox escape itself.
Crowdsourced verification payload.
Run this on the target Windows endpoint or via your endpoint management/remote shell tooling. Invoke it with powershell -ExecutionPolicy Bypass -File .\Test-ChromeCVE-2026-11056.ps1; local admin is recommended so the script can inspect both machine-wide install paths and all users' desktop app installs. It prints VULNERABLE, PATCHED, or UNKNOWN and exits 1, 0, or 2 respectively.
# Test-ChromeCVE-2026-11056.ps1
# Checks Google Chrome version on Windows for CVE-2026-11056
# Vulnerable if any discovered chrome.exe version is lower than 149.0.7827.53
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
param()
$ErrorActionPreference = 'SilentlyContinue'
$PatchedVersion = [version]'149.0.7827.53'
function Get-ChromeCandidates {
$paths = New-Object System.Collections.Generic.List[string]
$staticPaths = @(
"$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
"$env:ProgramFiles(x86)\Google\Chrome\Application\chrome.exe",
"$env:LocalAppData\Google\Chrome\Application\chrome.exe"
)
foreach ($p in $staticPaths) {
if ($p -and (Test-Path $p)) { [void]$paths.Add($p) }
}
# All local user profiles (best-effort)
$userRoot = Join-Path $env:SystemDrive 'Users'
if (Test-Path $userRoot) {
Get-ChildItem -Path $userRoot -Directory | ForEach-Object {
$candidate = Join-Path $_.FullName 'AppData\Local\Google\Chrome\Application\chrome.exe'
if (Test-Path $candidate) { [void]$paths.Add($candidate) }
}
}
# Registry uninstall keys (best-effort)
$regPaths = @(
'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
foreach ($rp in $regPaths) {
Get-ItemProperty -Path $rp | Where-Object {
$_.DisplayName -match 'Google Chrome' -and $_.InstallLocation
} | ForEach-Object {
$candidate = Join-Path $_.InstallLocation 'chrome.exe'
if (Test-Path $candidate) { [void]$paths.Add($candidate) }
}
}
return $paths | Sort-Object -Unique
}
function Get-FileVersionObject([string]$Path) {
try {
$fv = (Get-Item $Path).VersionInfo.FileVersion
if (-not $fv) { return $null }
# Normalize any extra suffixes if present
$match = [regex]::Match($fv, '\d+\.\d+\.\d+\.\d+')
if (-not $match.Success) { return $null }
return [version]$match.Value
}
catch {
return $null
}
}
$candidates = Get-ChromeCandidates
if (-not $candidates -or $candidates.Count -eq 0) {
Write-Output 'UNKNOWN - Google Chrome executable not found on this host'
exit 2
}
$results = @()
foreach ($path in $candidates) {
$ver = Get-FileVersionObject -Path $path
if ($null -ne $ver) {
$results += [pscustomobject]@{
Path = $path
Version = $ver
Vulnerable = ($ver -lt $PatchedVersion)
}
}
}
if (-not $results -or $results.Count -eq 0) {
Write-Output 'UNKNOWN - Chrome found but version could not be determined'
exit 2
}
$vuln = $results | Where-Object { $_.Vulnerable }
if ($vuln) {
Write-Output 'VULNERABLE'
$vuln | Sort-Object Version | ForEach-Object {
Write-Output ("{0} :: {1}" -f $_.Path, $_.Version)
}
exit 1
}
else {
Write-Output 'PATCHED'
$results | Sort-Object Version | ForEach-Object {
Write-Output ("{0} :: {1}" -f $_.Path, $_.Version)
}
exit 0
}
If you remember one thing.
Sources
- NVD CVE-2026-11056 detail
- Chrome Releases: Early Stable Update for Desktop (149.0.7827.53/.54)
- Chrome Releases: Stable Channel Update for Desktop
- Chromium security: Site Isolation overview
- Chromium Site Isolation design document
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS overview
- Censys overview of internet-wide scanning
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.