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

Insufficient validation of untrusted input in SiteIsolation in Google Chrome on Windows prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"This is not a drive-by by itself; it is a Windows-only sandbox escape that needs a prior renderer compromise."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on attacker-controlled web content

The operator needs the user to open a malicious page or hostile ad frame in Chrome on Windows. This CVE does nothing at this stage by itself; it only becomes reachable as part of a broader browser exploit chain.
Conditions required:
  • Target uses Chrome on Windows
  • Version is below 149.0.7827.53
  • User opens attacker-controlled content
Where this breaks in practice:
  • 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
Detection/coverage: Network and secure web gateway telemetry may catch the lure domain, but version scanners cannot infer exploitation from this step alone.
STEP 02

Exploit a separate renderer bug first

Per the official description, the attacker must already have a compromised renderer process. In practice that means a separate weaponized renderer exploit in V8, Blink, ANGLE, Media, or similar browser attack surface is required before CVE-2026-11056 even matters.
Conditions required:
  • A reliable renderer compromise exists and works against the target build
  • The page reaches the vulnerable renderer code path
Where this breaks in practice:
  • 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
Detection/coverage: EDR may see browser crashes, child-process anomalies, or exploit-mitigation events, but commodity vulnerability scanners only report version exposure.
STEP 03

Abuse Site Isolation validation to cross the sandbox boundary

With renderer control already in hand, the attacker abuses the Site Isolation input-validation flaw via crafted HTML to attempt a sandbox escape on Windows. This is the actual contribution of CVE-2026-11056: turning a renderer foothold into something more privileged than the renderer sandbox should allow.
Conditions required:
  • Renderer process is already compromised
  • Target is Windows
  • Chrome is prior to 149.0.7827.53
Where this breaks in practice:
  • 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
Detection/coverage: Very little direct signature coverage. Detection is mostly indirect through browser instability, exploit-prevention telemetry, or suspicious brokered actions from chrome.exe.
STEP 04

Execute post-escape actions on the endpoint

If the sandbox escape succeeds, the operator can run follow-on payloads in a less constrained context than the renderer. That can turn a browser bug chain into endpoint compromise, subject to the rights of the logged-in user and whatever EDR, ASR, or application-control stack sits on the box.
Conditions required:
  • Successful sandbox escape
  • Follow-on payload or living-off-the-land action available
Where this breaks in practice:
  • 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
Detection/coverage: This is where defenders have the best shot: EDR process ancestry, memory-protection alerts, suspicious child processes from chrome.exe, and unusual file/network actions.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation was found in the browsed sources, and it is not listed in CISA KEV.
Proof-of-concept availabilityNo public PoC or Metasploit-style weaponization was located. The referenced Chromium bug 498887785 is access-restricted.
EPSS0.00047 from the supplied intel — extremely low predicted near-term exploitation probability. Percentile was not verified from primary sources.
KEV statusAbsent from the CISA Known Exploited Vulnerabilities Catalog as checked against the current catalog source.
CVSS vs realityNVD 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 versionsChrome on Windows prior to 149.0.7827.53. This is not described as a Linux/macOS issue.
Fixed versionPatched 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 populationChrome 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 dataShodan/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 / reporterPublished 2026-06-04 in NVD. Public browsed sources do not name an external reporter; Chromium issue details are restricted.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.7/10)

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.

HIGH Attack-path prerequisite that a compromised renderer is required
MEDIUM Absence of public exploitation or PoC in browsed sources

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.00047 is 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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

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

If you remember one thing.

TL;DR
On Monday morning, have endpoint engineering pull a version report for Windows Chrome installs below 149.0.7827.53, fix any auto-update failures, and fold stragglers into your standard browser maintenance wave. After reassessment this is MEDIUM, so there is noisgate mitigation SLA — go straight to the 365-day remediation window under the noisgate remediation SLA; that said, because this is a sandbox-escape chain component in a ubiquitous browser, mature teams should usually clear it in their normal monthly browser cadence rather than letting it linger toward the outer limit.

Sources

  1. NVD CVE-2026-11056 detail
  2. Chrome Releases: Early Stable Update for Desktop (149.0.7827.53/.54)
  3. Chrome Releases: Stable Channel Update for Desktop
  4. Chromium security: Site Isolation overview
  5. Chromium Site Isolation design document
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS overview
  8. Censys overview of internet-wide scanning
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.