CVE-2026-11117 · Google Chrome Views UI Framework Use-After-Free on Windows

01 · The Real Story

This is a crack in the window frame, not a hole in the wall — the sandbox glass holds

CVE-2026-11117 is a use-after-free in Chromium's Views UI framework — the subsystem responsible for rendering browser chrome elements like menus, buttons, and dialog boxes. It affects Google Chrome on Windows only, in versions prior to 149.0.7827.53 (released June 4, 2026). A remote attacker can trigger the dangling pointer by serving a crafted HTML page that manipulates Views object lifetimes during rapid UI element creation/destruction. The CVSS vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) yields 8.8 HIGH, and the NVD dutifully parrots it.

The vendor severity label is misleading — and the vendor *knows* it. Chromium's own security team classified this bug as Medium, not High. Red Hat independently concurs at Moderate. The disconnect exists because CVSS has no mechanism to model Chrome's multi-process sandbox architecture. The S:U (Scope: Unchanged) in the vector confirms this bug does not escape the sandbox — code execution is confined to the browser process's sandboxed context. Compare this to CVE-2026-7343, a Views UAF that Chromium rated Critical because it *did* enable sandbox escape from a compromised renderer. CVE-2026-11117 is not that bug. The 8.8 makes it look like a hair-on-fire RCE when it's actually a sandboxed crash-to-maybe-code-exec with no demonstrated path to the host OS.

"Chrome Views UAF is sandbox-contained; Chromium rates it Medium, and no one has weaponized it."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Attacker hosts weaponized page

The attacker crafts an HTML page that triggers rapid creation and destruction of Views UI elements (e.g., pop-up menus, tooltips, or dialogs) to provoke the use-after-free condition. This requires a deep understanding of Views object lifetimes and heap layout. No public PoC or exploit code exists for CVE-2026-11117 as of September 2026.

Conditions required:

Attacker controls or compromises a web server or ad network to serve the payload

Where this breaks in practice:

No public PoC exists — attacker must develop the exploit from scratch against a specific Chrome build
Views UAF exploitation requires heap grooming specific to the Windows allocator and Chrome version

STEP 02

Victim navigates to malicious page

The victim must open the attacker-controlled URL in a vulnerable Chrome version on Windows. This requires either a phishing lure, a watering-hole, or a malvertising placement. The user interaction requirement (UI:R in the CVSS vector) means passive drive-by without any click is insufficient — the page must be actively loaded.

Conditions required:

Victim is running Chrome < 149.0.7827.53 on Windows
Victim clicks a link or navigates to attacker-controlled content

Where this breaks in practice:

Chrome auto-updates aggressively — the 149.0.7827.53 patch shipped June 4, 2026; most managed fleets patched within 1-2 weeks
Enterprise email gateways and web proxies filter known-malicious URLs
Security-aware users on managed devices are unlikely to reach novel phishing domains

Detection/coverage: URL reputation services (Google Safe Browsing, Microsoft SmartScreen, Zscaler) flag known malicious domains; email gateway sandboxing detonates links pre-delivery

STEP 03

UAF triggers in Views component

The crafted page causes a Views object to be freed while a dangling pointer still references it. On the next access through the stale pointer, the attacker attempts to reclaim the freed memory with controlled data (heap spray/grooming). The goal is to convert the UAF into a write-what-where primitive within the browser process.

Conditions required:

Victim's Chrome build matches the attacker's heap layout assumptions
ASLR and CFI do not defeat the grooming strategy

Where this breaks in practice:

Chrome ships with Control Flow Integrity (CFI), MiraclePtr (pointer safety for UAFs), and PartitionAlloc hardening — all raise the exploitation bar significantly
MiraclePtr specifically targets use-after-free by poisoning dangling pointers, and has been progressively covering more objects in the browser process since Chrome 128+
Windows ASLR + Chrome's own ASLR add entropy that the heap groom must account for

Detection/coverage: Chrome's CrashPad telemetry and Windows Error Reporting capture abnormal renderer/browser process crashes; anomalous crash spikes on endpoints are a signal

STEP 04

Code execution within sandbox

If the heap groom succeeds, the attacker achieves arbitrary code execution. However, the scope is Unchanged (S:U): execution occurs within the sandboxed browser process. The attacker can read browsing-session data (cookies, form data, in-memory credentials for the active tab) but cannot directly access the host filesystem, registry, or other processes.

Conditions required:

Heap groom succeeds against all runtime mitigations

Where this breaks in practice:

The sandbox blocks file system access, registry writes, process creation, and network access outside the browser's allowed policy
Without a sandbox escape (a second, separate vulnerability), the attacker is trapped inside the browser process
No sandbox escape chain has been demonstrated for CVE-2026-11117

Detection/coverage: EDR agents (CrowdStrike, Defender for Endpoint, SentinelOne) monitor for anomalous child-process creation from chrome.exe and suspicious memory access patterns; sandbox violations trigger kernel-level alerts

03 · Compensating Control

MEDIUM 5.5→IGNORE 0.0

SEVERITY REDUCED

Verify Chrome auto-update is functioning fleet-wide — The single most effective control. Use Chrome Enterprise reporting, Tanium, SCCM, or Qualys agent to confirm all Windows endpoints are running Chrome ≥ 149.0.7827.53. Flag any endpoint stuck on an older version. Since the noisgate verdict is MEDIUM, the remediation SLA is 365 days — but Chrome's auto-update should have already handled this. Focus on finding the stragglers.

MEDIUM 5.5→IGNORE 0.0

SEVERITY REDUCED

Enforce Chrome browser version policy via GPO or MDM — Set TargetVersionPrefix in Chrome Enterprise policy to pin the minimum allowed version to 149.0.7827.53 or later. This prevents rollback and forces update on next launch. Deploy within the standard change window — no mitigation SLA for MEDIUM, so go straight to the 365-day remediation window.

MEDIUM 5.5→LOW 3.5

SEVERITY REDUCED

Enable Site Isolation and strict site-per-process — Ensure SitePerProcess is enabled (it is by default since Chrome 67, but verify via policy). Site Isolation limits the data an attacker can access from a compromised renderer to a single origin, reducing the value of session-data theft even if the UAF is triggered.

MEDIUM 5.5→LOW 3.0

SEVERITY REDUCED

Deploy browser-level URL filtering and Safe Browsing enforcement — Ensure Chrome's Enhanced Safe Browsing is enabled via policy (SafeBrowsingProtectionLevel = 2). Layer a secure web gateway (Zscaler, Netskope, Palo Prisma Access) for URL reputation and content inspection. This reduces the probability the victim ever reaches the attacker's crafted page.

What doesn't work

Network segmentation — This is a client-side browser vulnerability triggered by visiting a web page. Network segmentation between server VLANs has no effect on whether a user's browser visits a malicious URL.
WAF rules — A WAF protects server-side applications. The exploit payload is served *to* the browser, not *from* it. WAF inspection of outbound traffic won't catch a page that triggers a Views UAF.
Disabling JavaScript — The Views UAF is in the browser's UI framework, not in V8. While disabling JS would prevent many attack chains, it would break virtually all web applications and is not a viable enterprise control.

04 · Intelligence Metadata

The supporting signals.

In-the-Wild Exploitation	None observed. Not listed in CISA KEV. Google's Chrome 149 release notes state no patched vulnerabilities were exploited in the wild. No campaign attribution from Mandiant, Google TAG, or Microsoft MSTIC.
Proof-of-Concept	No public PoC. Checked pocindex.io, ExploitDB, GitHub (no repos targeting CVE-2026-11117 specifically — one unrelated KRACK-simulation repo reuses the CVE ID). SecureWithUmer/CVE-2026-PoCs aggregator does not list it. The Chromium bug (#501403820) is likely still access-restricted.
EPSS	0.00306 (0.31%) — 23rd percentile. Bottom quartile; the model sees almost no signal that this will be exploited in the next 30 days.
KEV Status	Not listed. No CISA KEV entry as of 2026-09-30.
CVSS Vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H` — The critical detail is S:U (Scope Unchanged): impact stays within the vulnerable component's security boundary (the sandbox). The 8.8 score is mechanically correct but architecturally misleading.
Chromium Severity	Medium — Chromium's own security team classified this as Medium, not High. Red Hat independently rates it Moderate. Ubuntu rates it Medium. The three vendors closest to the code all disagree with the NVD 8.8.
Affected Versions	Google Chrome on Windows only, versions < 149.0.7827.53. macOS and Linux builds are unaffected. Chromium-based browsers (Edge, Brave, Opera, Vivaldi) that incorporate the same Views code at equivalent version ranges are also affected.
Fixed Version	149.0.7827.53 (Stable channel, released June 4, 2026). Microsoft Edge typically picks up Chromium patches within 1-2 weeks. Ubuntu/Debian note chromium-browser is snap-delivered and tracks upstream.
Scanning / Exposure	Browser vulnerabilities are not typically visible via Shodan/Censys/GreyNoise (client-side, not server-side). Enterprise exposure is measured by browser version inventory — tools like Google Chrome Enterprise, Tanium, SCCM, or Qualys agent can report unpatched Chrome instances across the fleet.
Researcher / Reporter	Not publicly disclosed. Chromium bug #501403820 remains restricted. The Chrome 149 release patched 429 vulnerabilities total — 371 found internally by Google, remainder by external researchers.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (5.5/10)

Why this verdict

Chromium's own team says Medium. The vendor closest to the code — with full knowledge of the bug's triggering conditions, heap layout constraints, and sandbox interaction — rates this Medium, not High. Red Hat (Moderate) and Ubuntu (Medium) independently agree. Three informed vendors overrule a mechanical CVSS 8.8.
Sandbox containment (S:U) caps the blast radius. The CVSS Scope: Unchanged confirms code execution is confined to the sandboxed browser process. The attacker cannot touch the host OS, filesystem, registry, or other processes without a *separate* sandbox-escape vulnerability — none has been chained with this CVE. Compare to CVE-2026-7343 (Views UAF rated Critical by Chromium) which *was* a sandbox escape.
No PoC, no exploitation, bottom-quartile EPSS. EPSS 0.31% (23rd percentile) signals near-zero exploitation probability. No in-the-wild activity. No KEV listing. No public exploit code. Chrome's MiraclePtr, CFI, and PartitionAlloc mitigations make reliable exploitation materially harder even for a motivated attacker.
Chrome auto-updates collapse the exposure window. Enterprise Chrome fleets with Google Update or SCCM-managed deployment typically absorb stable-channel patches within 7-14 days. The June 4 fix is nearly 4 months old — residual exposure is limited to unmanaged or abandoned installations.
Windows-only narrows the target surface. macOS and Linux Chrome users (~25-30% of enterprise browser installs) are not affected, reducing the addressable fleet.
Role multiplier: Chrome is an endpoint application (web browser), not infrastructure. It does not occupy a high-value deployment role (not an IdP, DC, hypervisor, CI/CD server, backup agent, or network edge appliance). A sandboxed UAF in a browser process does not produce domain-takeover, fleet-compromise, or supply-chain outcomes. The high-value-role floor does *not* apply. Blast radius per successful exploitation: host-session-scoped (cookies, form data, in-memory credentials for active tabs) — not host-level, not domain-level, not fleet-level.

Why not higher?

The CVSS 8.8 / HIGH assessment would be appropriate if this bug escaped the sandbox or if Chromium's own security team rated it High or Critical. Neither is the case. CVE-2026-7343 — a Views UAF that *did* enable sandbox escape — was rated Critical by Chromium; CVE-2026-11117 was explicitly rated Medium. The absence of any PoC, any in-the-wild exploitation, and the sub-1% EPSS further confirm that the mechanical CVSS overestimates the real risk. Upgrading to HIGH would require either demonstrated sandbox escape or active exploitation — neither exists.

Why not lower?

Despite the sandbox containment, the attack vector is network-accessible with low complexity (AV:N/AC:L), and Chrome is installed on virtually every Windows workstation in the enterprise. A successful exploit — even sandboxed — gives the attacker access to session cookies, authentication tokens, and form data for all tabs in the affected browser process, which can include SSO tokens and cloud console sessions. The UAF class in Chrome's browser process is a proven research target, and the absence of a PoC today doesn't guarantee one won't appear. LOW would understate the residual session-theft risk.

06 · Verification

Crowdsourced verification payload.

Run on each Windows endpoint (or push via SCCM/Intune/Tanium). No admin privileges required — reads Chrome's version from the registry and filesystem. Example: powershell -ExecutionPolicy Bypass -File .\Check-CVE-2026-11117.ps1

noisgate-verify.ps1

POWERSHELLREAD-ONLYSAFE

#!/usr/bin/env pwsh
# Check-CVE-2026-11117.ps1
# Detects whether Google Chrome on Windows is vulnerable to CVE-2026-11117
# (Use after free in Views, fixed in 149.0.7827.53)
# Exit codes: 1 = VULNERABLE, 0 = PATCHED, 2 = UNKNOWN

$FixedVersion = [version]'149.0.7827.53'
$ChromePaths = @(
    'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe',
    'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe'
)
$ChromeExe = $null

# Try registry first
foreach ($regPath in $ChromePaths) {
    if (Test-Path $regPath) {
        $ChromeExe = (Get-ItemProperty $regPath -ErrorAction SilentlyContinue).'(default)'
        if ($ChromeExe -and (Test-Path $ChromeExe)) { break }
        $ChromeExe = $null
    }
}

# Fallback to common paths
if (-not $ChromeExe) {
    $fallbacks = @(
        "$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 $fallbacks) {
        if (Test-Path $p) { $ChromeExe = $p; break }
    }
}

if (-not $ChromeExe -or -not (Test-Path $ChromeExe)) {
    Write-Output 'UNKNOWN - Google Chrome not found on this system'
    exit 2
}

try {
    $verInfo = (Get-Item $ChromeExe).VersionInfo
    $installed = [version]$verInfo.ProductVersion
} catch {
    Write-Output "UNKNOWN - Could not read version from $ChromeExe"
    exit 2
}

Write-Output "Chrome path   : $ChromeExe"
Write-Output "Installed ver : $installed"
Write-Output "Fixed ver     : $FixedVersion"

if ($installed -lt $FixedVersion) {
    Write-Output 'VULNERABLE - Chrome version is below 149.0.7827.53 (CVE-2026-11117)'
    exit 1
} else {
    Write-Output 'PATCHED - Chrome version is 149.0.7827.53 or later'
    exit 0
}