← Back to Feed CACHED · 2026-07-02 06:12:04 · CACHE_KEY CVE-2026-14425
CVE-2026-14425 · CWE-416 · Disclosed 2026-07-01

Use after free in ANGLE in Google Chrome prior to 150

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

A poisoned WebGL shader that escapes the browser sandbox and lands as the user who opened the tab

ANGLE is Chrome's translation layer between WebGL/WebGPU calls and the host graphics stack (Direct3D on Windows, Metal on macOS, GL/Vulkan on Linux). A use-after-free in ANGLE means a maliciously crafted HTML page — one drive-by ad, one iframe, one embedded MP4 preview — can hand the attacker a dangling pointer inside the *GPU process*. The GPU process runs at a higher privilege tier than the renderer sandbox, so a bug here is the classic sandbox-escape primitive. Affected: all Chrome/Chromium-based browsers on Stable prior to 150.0.7871.46; expect Edge, Brave, Opera, Vivaldi, and Electron apps to inherit until they respin.

Google's 9.6 CRITICAL is defensible on paper — network attack vector, low complexity, scope-changed to SYSTEM-tier impact. In practice, ANGLE UAFs are almost always half of a chain: you still need a renderer RCE first to reach the ANGLE IPC surface, or a *very* creative WebGL primitive that bypasses Chrome's Site Isolation. That makes the real-world severity closer to HIGH unless and until a public one-click exploit lands, which is why we downshift from 9.6 to 8.4.

"ANGLE UAF chained with a renderer bug means SYSTEM in a tab — but no in-the-wild exploitation yet. Push Chrome 150.0.7871.46 on your normal Stable train."
02 · The Attack Path

4 steps from start to impact.

STEP 01

User loads attacker-controlled content

Victim visits a malicious page, malvertising slot, or compromised legitimate site. Delivery can be a direct visit, an iframe, or a background prefetch. No credentials, no interaction beyond a page load. Tools: BeEF, custom landing pages, malvertising via Google Ads / Taboola resellers.
Conditions required:
  • Chrome/Chromium < 150.0.7871.46
  • JavaScript enabled
  • GPU process enabled (default)
Where this breaks in practice:
  • Enterprise DNS/HTTP filtering (Umbrella, Zscaler, Netskope) blocks known malicious hosts
  • Ad-blockers strip most malvertising vectors
  • Site Isolation confines the initial renderer per-origin
Detection/coverage: Proxy telemetry on newly-registered domains; EDR web-content inspection.
STEP 02

Trigger the ANGLE UAF via crafted WebGL/WebGPU

The page issues a carefully sequenced WebGL draw call that frees an ANGLE-managed resource then reuses it. This yields a controllable dangling pointer inside the GPU process. Public research on prior Chrome ANGLE UAFs (CVE-2023-2033, CVE-2024-4671) shows type confusion on gl::Texture and ProgramExecutable objects is the usual primitive.
Conditions required:
  • Renderer or content process can talk to GpuChannel (default)
  • ANGLE backend matches attacker's shader payload (D3D11 on Windows)
Where this breaks in practice:
  • Chrome ships MiraclePtr/BackupRefPtr which neutralizes many UAFs on Windows x64 renderer heaps
  • GPU process on Windows has its own restrictive token
  • V8 sandbox limits leak-then-corrupt patterns
Detection/coverage: GPU-process crashes surface as chrome_watcher events; Chrome Enterprise crash reports if opted in.
STEP 03

Escape the renderer sandbox into the GPU process

Once the UAF gives arbitrary read/write inside the GPU process, the attacker pivots there. GPU process is *not* the renderer sandbox — it has broader access to graphics drivers and can reach kernel-mode GPU IOCTLs. Tooling: custom shader chain, no public PoC as of writing.
Conditions required:
  • Reliable heap groom in the GPU process
  • Bypass of ASLR inside GPU process
Where this breaks in practice:
  • CFG / CET on Windows 11 and modern macOS breaks naive ROP
  • GPU driver telemetry (Nvidia/AMD) may crash instead of executing
Detection/coverage: Windows Event 1000 for gpu-process.exe crashes at anomalous rate; Defender ATP surfaces process-integrity anomalies.
STEP 04

Land code as the logged-on user

From GPU-process code execution the attacker either drops a payload to disk under the user profile or pivots to a kernel-mode GPU driver bug for full SYSTEM. For a commodity attacker, user-tier code execution is enough for infostealer / cookie theft (RedLine, Lumma, StealC).
Conditions required:
  • Persistence achievable in user context
  • AV/EDR bypass
Where this breaks in practice:
  • EDR (CrowdStrike, SentinelOne, Defender for Endpoint) flags unsigned child processes from chrome.exe
  • AppLocker / WDAC in Enforced mode blocks unsigned executables
  • Cookie encryption (App-Bound Encryption in Chrome 127+) limits credential theft blast radius
Detection/coverage: EDR parent-child anomaly rules; Chrome enterprise reporting connector.
03 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNone reported as of 2026-07-02. Not on CISA KEV. Google's advisory does not include the *'exists in the wild'* language it reserves for actively-exploited zero-days.
Public PoCNo public PoC at disclosure. Historical pattern: Chromium ANGLE UAFs get partial PoCs within 2-4 weeks once the fix lands in the Chromium source and diffing is possible.
EPSSNot yet scored (new CVE). Comparable Chrome ANGLE UAFs sit at *EPSS 0.5-3%* until PoC availability.
KEV statusNot listed on CISA KEV as of 2026-07-02.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H — network, low complexity, no privs, user interaction required (visit a page), scope-changed to sandbox escape.
Affected versionsChrome/Chromium < 150.0.7871.46 on Windows/Mac/Linux. Downstream: Edge, Brave, Opera, Vivaldi, Electron — all vulnerable until each vendor respins.
Fixed versionChrome Stable 150.0.7871.46 (Win/Mac), 150.0.7871.44 (Linux). Edge fix expected within 5-10 days per Microsoft's cadence.
Exposure telemetryChrome ~65% desktop share per StatCounter; assume ~90% of your fleet has some Chromium-derived browser installed. Auto-update reaches most consumer installs within 72h; managed enterprise fleets on pinned versions are the exposed tail.
Disclosure / reporterDisclosed 2026-07-01 in the Chrome Stable channel update. Credit typically noted in the Chrome Releases blog — check that entry for the researcher (often Google Project Zero, Qihoo 360, or a bounty hunter).
Related classesSame family as CVE-2023-2033, CVE-2024-4671, CVE-2026-10881 (ANGLE OOB) — Chrome's *most-patched* subsystem alongside V8.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to HIGH (8.4/10)

Downgraded one notch from vendor CRITICAL because no in-the-wild exploitation and no public PoC exist at disclosure — the single decisive factor. The bug is still a real sandbox-escape primitive on a browser installed on nearly every endpoint, which is why it stays firmly in HIGH and does not slide to MEDIUM.

HIGH technical assessment of affected versions and fix
MEDIUM exploit weaponization timeline
LOW whether a full chain (renderer RCE + this ANGLE bug) exists in a private toolkit

Why this verdict

  • No active exploitation: Google's advisory lacks the 'exists in the wild' marker; not on KEV. That's the single biggest downshift from 9.6.
  • User interaction required: UI:R — the victim must load attacker content. Not wormable, not driveable by a Shodan scan.
  • Chain-dependent in practice: an ANGLE UAF alone is a sandbox-escape *half*. Weaponization needs either a renderer RCE or a WebGL primitive that reaches GPU-process IPC without a renderer bug — non-trivial.
  • Role multiplier — endpoint browsers: Chain succeeds in typical role (user workstation) with blast radius = single-user credential theft + cookie exfil. Not fleet-scale on its own, but multiplied across a 10k-host fleet the aggregate risk is meaningful → HIGH is the floor, not MEDIUM.
  • Role multiplier — jump hosts / admin workstations: If admins browse from PAWs or jump hosts running Chromium, a successful chain gives an attacker session tokens for Azure AD, AWS console, GitHub — that is the fleet-scale path and it prevents any downgrade below HIGH.
  • Auto-update reduces blast radius fast: Chrome's silent updater closes exposure within 24-72h on unmanaged installs. The exposed population is your *pinned/managed* fleet, which is smaller but slower to patch.

Why not higher?

CRITICAL is reserved for bugs with public PoC, active exploitation, or unauthenticated RCE without user interaction. This one requires visiting attacker content, has no public exploit at disclosure, and is almost always chained rather than standalone — the vendor 9.6 reflects the theoretical worst case, not observed reality on day one.

Why not lower?

MEDIUM would ignore that the affected component is on ~90% of your endpoints, that GPU-process escape is a real primitive Google has paid four- and five-figure bounties for, and that admin browsing sessions are a fleet-scale credential-theft vector. The role multiplier on admin/PAW browsers alone floors this at HIGH.

05 · Compensating Control

What to do — in priority order.

  1. Force Chrome Stable to 150.0.7871.46 via GPO / MDM — Use the ChromiumUpdateOverride / Google Update AutoUpdateCheckPeriodMinutes policy to force an update check now rather than waiting for the default 5-hour poll. On macOS use Jamf/Kandji Chrome config profile; on Windows use the Chrome Enterprise ADMX. Deploy within 30 days per noisgate mitigation SLA for HIGH.
  2. Kill pinned browser versions — Audit your fleet for Chrome/Chromium/Edge/Brave versions pinned by app-compat exceptions. Those hosts are your exposure. Sweep and unpin within 30 days; for Electron apps, push vendor updates on the same clock.
  3. Enforce Site Isolation and disable legacy WebGL fallbacks — Set SitePerProcess=Enabled and WebGL2Enabled policies to control the attack surface. For very sensitive fleets (admin PAWs, DFIR workstations) set Disable3DAPIs=1 to remove ANGLE reachability entirely until patched.
  4. Tighten browser egress on admin workstations — Jump hosts, PAWs, and Tier-0 admin endpoints should only reach a documented allowlist of cloud consoles. This limits the malvertising/drive-by delivery surface for the users whose credential theft would hurt most.
  5. Turn on Chrome Enterprise reporting connector — Ship crash and safe-browsing signals to your SIEM. GPU-process crashes at anomalous rates on a single host are one of the few in-the-wild indicators you'll get before public IOCs land.
What doesn't work
  • Web Application Firewall — the malicious content is inbound to the user's browser from the internet, not an application you protect with a WAF.
  • Network IPS signatures — the exploit is a JavaScript/shader payload delivered over TLS. Without TLS interception plus a signature (which does not exist yet), IPS is blind.
  • MFA — this is client-side code execution stealing session cookies and tokens *after* the user is authenticated. MFA does not prevent cookie/token replay.
  • Blocking chrome.exe egress — impractical; users need the browser to work.
06 · Verification

Crowdsourced verification payload.

Run on each Windows endpoint (via SCCM, Intune Proactive Remediations, or Invoke-Command from an auditor workstation). Requires standard user rights to read the installed Chrome version. Example: powershell -ExecutionPolicy Bypass -File Check-CVE-2026-14425.ps1.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# Check-CVE-2026-14425.ps1
# Detects Chrome installs vulnerable to CVE-2026-14425 (ANGLE UAF)
# Fixed in Chrome 150.0.7871.46 (Windows/Mac), 150.0.7871.44 (Linux)
# Output: VULNERABLE / PATCHED / UNKNOWN

$ErrorActionPreference = 'SilentlyContinue'
$FIXED = [Version]'150.0.7871.46'

$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"
) | Where-Object { Test-Path $_ }

if (-not $paths) {
  Write-Output 'UNKNOWN: no Chromium-family browser found'
  exit 2
}

$verdict = 'PATCHED'
foreach ($p in $paths) {
  try {
    $ver = (Get-Item $p).VersionInfo.ProductVersion
    $v   = [Version]($ver -replace '[^\d\.].*$','')
    $tag = if ($v -lt $FIXED) { 'VULNERABLE' } else { 'PATCHED' }
    Write-Output "$tag`t$p`t$ver"
    if ($tag -eq 'VULNERABLE') { $verdict = 'VULNERABLE' }
  } catch {
    Write-Output "UNKNOWN`t$p`t$($_.Exception.Message)"
    if ($verdict -ne 'VULNERABLE') { $verdict = 'UNKNOWN' }
  }
}

switch ($verdict) {
  'VULNERABLE' { exit 1 }
  'PATCHED'    { exit 0 }
  default      { exit 2 }
}
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: push Chrome 150.0.7871.46 through your Stable channel now and force an update check via policy — do not wait for the 5-hour default poll. Under the noisgate mitigation SLA for HIGH you have 30 days to deploy compensating controls (unpin versions, enforce Site Isolation, tighten egress on admin workstations), and under the noisgate remediation SLA you have 180 days to reach full fleet coverage including Edge, Brave, Opera, Vivaldi, and every Electron app your developers ship. Realistically you should be done inside 14 days — Chromium-derivative respins land within a week and stragglers are usually version-pinned app-compat exceptions your CMDB already knows about. If a public PoC lands or Google adds *'exists in the wild'* language to the advisory, escalate to the CRITICAL rail (patch/mitigate within hours) immediately.

Sources

  1. Chrome Releases blog (Stable channel updates)
  2. Chrome Enterprise policy list
  3. Chromium bug tracker / ANGLE component
  4. CISA KEV catalog
  5. FIRST EPSS scoring
  6. Microsoft Edge security release notes
  7. Chromium Site Isolation design
  8. Related — CVE-2026-10881 ANGLE analysis
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.