A dangling pointer in Chrome's window-chrome code that a hostile page can dance on until it lands arbitrary writes in the browser process
CVE-2026-15129 is a use-after-free (CWE-416) in Chromium's Views UI framework — the toolkit that draws tabs, dialogs, omnibox popups, and permission prompts. A crafted page (or embedded content that triggers a Views-managed dialog/prompt lifecycle) can free a Views object while another reference is still live, then reclaim the slot with attacker-controlled data. All Chrome, Chromium, Edge, Brave, Opera, and Electron builds prior to the 150.0.7871.115 milestone inherit the flaw.
There is no vendor CVSS on this ID yet — Google historically labels this class 'High' in the Chrome VRP because Views runs in the privileged browser process, not the sandboxed renderer. That means a successful exploit skips the usual sandbox-escape stage entirely. On real-world fleet math (near-universal Chromium presence, drive-by delivery, no auth required) treating this as anything less than HIGH is optimistic; we agree with the implicit Google grading.
5 steps from start to impact.
Deliver hostile web content
- Victim visits attacker-controlled or attacker-injected content
- Target Chrome/Chromium build < 150.0.7871.115
- Enterprise web filtering / Safe Browsing may block known-bad domains
- Isolated browsing profiles or remote-browser isolation (Menlo, Cloudflare Browser Isolation) neutralize drive-by delivery
Trigger the Views UAF
- JS execution in the tab
- Ability to open/close a Views-owned dialog surface
- Site Isolation limits cross-origin leaks
- V8 heap hardening (
MiraclePtr/ BackupRefPtr on Views raw pointers) may convert the UAF into a safe crash instead of a corruption primitive
chrome.exe browser process crash loops.Convert UAF into arbitrary read/write
- MiraclePtr not covering the affected raw pointer
- Reliable heap-spray control from JS
- MiraclePtr / BackupRefPtr is Chrome's dedicated mitigation for exactly this bug class and defuses many Views UAFs since M102
- ASLR + CFG on Windows / PAC on Arm reduce reliability
Execute code in the browser process — no sandbox escape needed
- Successful R/W primitive from step 3
- No app-container or Windows LPAC constraints on the browser process (default)
- Windows App Container + LPAC deployment is rare
- macOS hardened runtime + TCC prompts constrain filesystem pivots
chrome.exe spawning suspicious children or making atypical filesystem/registry calls; Chrome Enterprise Connectors surface extension installs.Persistence + credential theft
- Code execution as the interactive user
- FIDO2 / hardware-bound sessions (device-bound session credentials) resist token replay
- Conditional access with device posture gates SSO reuse
IsolateOrigins=* and SitePerProcess=true via GPO/MDM; enable SafeBrowsingProtectionLevel=2 (Enhanced). Reduces cross-origin leak surface and blocks a large fraction of drive-by delivery.- Network IDS signatures — the trigger is JS in a TLS-encrypted page; you cannot signature the UAF wire-side.
- EDR memory scanning of
chrome.exe— Chrome legitimately allocates and frees millions of Views objects per session; no useful behavioral signal until post-exploitation. - Sandbox tightening (LPAC, App Container) — Views already runs OUTSIDE the sandbox in the browser process; sandbox hardening does not apply.
- Blocking JIT (
JavaScriptJitDisabled) — helps against v8 JIT bugs; this is a UI-framework UAF, not a JIT issue.
The supporting signals.
| In-the-wild | No confirmed ITW as of 2026-07-09; Chrome release notes do not flag an 'exploit exists in the wild' tag for this ID. Chrome Views UAFs have historically been weaponized post-disclosure within 2–6 weeks. |
|---|---|
| KEV status | Not KEV-listed as of 2026-07-09. |
| EPSS | Not yet scored (< 72h since disclosure). Chrome UAFs in Views typically land in the 0.5–5% range within 30 days. |
| Proof-of-concept | No public PoC at time of writing. Chromium bug tracker entry is embargoed until majority of users have patched (standard Google 14-week policy). |
| CVSS vector | No vendor CVSS. Assessed vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H → 8.3 High. Network vector, requires visiting a page (UI:R), high complexity (heap grooming + MiraclePtr bypass), browser-process impact. |
| Affected versions | All Chromium-based browsers with a Views build < 150.0.7871.115 — Chrome Stable, Edge (pre corresponding Edge Stable), Brave, Opera, Vivaldi, and Electron apps (Slack, Teams desktop, Discord, VS Code webviews) bundling an older Chromium. |
| Fixed versions | Chrome 150.0.7871.115 (Stable) and later. Edge, Brave, Opera respins follow within 3–10 days. Electron: expect Electron 32.x / 33.x patch releases. |
| Exposure telemetry | GreyNoise / Shodan don't apply (client-side). StatCounter: Chromium family = ~72% of desktop browsers. Enterprise Chrome install base is effectively universal. |
| Disclosure | 2026-07-08 via Chrome Stable channel update; reporter credited in the Chrome Releases blog post. |
| Bug class | CWE-416 Use-After-Free in Views — the same class as CVE-2023-2033, CVE-2023-4863, CVE-2024-4671 (all HIGH, all weaponized). |
Sources.
- Chrome Releases — Stable Channel Update for Desktop
- Chromium Security — Views + MiraclePtr
- CWE-416: Use After Free
- CISA KEV Catalog
- FIRST EPSS
- Google Project Zero — Chrome exploit writeups
- Chrome Enterprise Policy List (RelaunchNotification, IsolateOrigins, SafeBrowsingProtectionLevel)
- Man Yue Mo — Chromium Views UAF research (GitHub Security Lab)
Why this verdict
- Browser-process impact: Views is not sandboxed — this is not a renderer bug that still needs a second CVE to matter. One bug, user-token code exec.
- Fleet ubiquity: Chromium is on nearly every managed endpoint. Delivery is drive-by; no auth, no lateral movement needed to reach the vulnerable surface.
- Class precedent: Every prior Views UAF in the last 24 months has been rated High by Google and several were weaponized within weeks of disclosure.
- Role multiplier: The affected component (browser) runs on workstations of admins, developers, and SSO-authenticated humans. A browser-process compromise on a domain-admin jumpbox or CI operator laptop ends in cookie theft → SSO replay → identity-provider access. Blast radius on privileged endpoints is fleet-scale via credential theft, not host-scale.
- Friction that keeps this at HIGH not CRITICAL: Requires user to visit attacker content (UI:R), MiraclePtr may neutralize the primitive, and enterprise SWG/isolation intercepts a meaningful fraction of drive-by traffic. No public PoC yet.
Why not higher?
Not CRITICAL because there is no confirmed in-the-wild exploitation, no public PoC, and Chrome's MiraclePtr / BackupRefPtr mitigation has historically converted a majority of Views UAFs into safe crashes. User interaction is required (page visit), which further compresses the reachable population versus a wormable network service.
Why not lower?
Not MEDIUM because the bug lives in the unsandboxed browser process, the affected install base is effectively every managed endpoint, and this bug class (Views UAF) has a strong precedent of successful weaponization. Cookie/token theft from a browser-process compromise routinely pivots into identity-provider access, which is not a MEDIUM-level outcome.
Crowdsourced verification payload.
Run on each Windows endpoint (or via your RMM / Intune script agent) as any user with read access to the Chrome install path. Invoke: .\Check-CVE-2026-15129.ps1. Emits VULNERABLE / PATCHED / UNKNOWN and exits with codes 1/0/2 respectively. macOS/Linux equivalents should check mdls / dpkg -s google-chrome-stable.
#requires -Version 5.1
# Check-CVE-2026-15129.ps1
# Detects Chrome / Edge / Brave builds vulnerable to CVE-2026-15129 (Views UAF)
# Fixed Chrome build: 150.0.7871.115
$ErrorActionPreference = 'SilentlyContinue'
$fixed = [Version]'150.0.7871.115'
$paths = @(
"$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
"${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe",
"$env:LOCALAPPDATA\Google\Chrome\Application\chrome.exe",
"$env:ProgramFiles\Microsoft\Edge\Application\msedge.exe",
"${env:ProgramFiles(x86)}\Microsoft\Edge\Application\msedge.exe",
"$env:ProgramFiles\BraveSoftware\Brave-Browser\Application\brave.exe"
)
$found = $false
$vulnerable = $false
foreach ($p in $paths) {
if (Test-Path $p) {
$found = $true
try {
$v = [Version](Get-Item $p).VersionInfo.ProductVersion
if ($v -lt $fixed) {
Write-Output "VULNERABLE: $p at $v (< $fixed)"
$vulnerable = $true
} else {
Write-Output "PATCHED: $p at $v"
}
} catch {
Write-Output "UNKNOWN: $p (could not parse version)"
}
}
}
if (-not $found) {
Write-Output 'UNKNOWN: no Chromium-family browser found in standard install paths'
exit 2
}
if ($vulnerable) { exit 1 } else { exit 0 }