Vulnerability Analysis | Mitigation Guide | Security Testing | Patch Management

CVE-2026-5281: Chrome's Fourth Zero-Day of 2026 — WebGPU Use-After-Free Under Active Exploitation

Executive Summary

CVE-2026-5281 is a use-after-free vulnerability in Dawn, Google Chrome's cross-platform WebGPU implementation, that has been confirmed exploited in the wild and added to CISA's Known Exploited Vulnerabilities (KEV) catalog. Rated CVSS 8.8 (High), a remote attacker can craft a malicious webpage that causes a victim's browser to execute arbitrary code simply by visiting the page. Google issued an emergency patch on April 1, 2026, updating Chrome to version 146.0.7680.177/178 — organizations that have not yet updated are exposed to active threat actor campaigns.

1. What Is This Vulnerability?

A use-after-free (UAF) vulnerability occurs when a program continues to use a pointer to memory that has already been freed (deallocated). In the case of CVE-2026-5281, the flaw resides in Dawn — the open-source, cross-platform C++ library that powers Chrome's implementation of the WebGPU graphics API.

The Technical Root Cause

Dawn maintains an internal sequential command queue to organize GPU command buffers submitted by JavaScript before they are dispatched to the underlying hardware API (Vulkan, Metal, DirectX). When a script calls gpuDevice.queue.submit(), Dawn allocates memory regions to track the asynchronous execution state of each submitted task.

The flaw arises from a race condition in Dawn's queue management system: under specific multi-threaded timing conditions, a GPU command buffer's backing memory can be freed (released) while a separate internal Dawn bookkeeping thread still holds and dereferences a raw pointer to that same memory region. This stale pointer access constitutes the use-after-free condition.

The resulting dangling pointer can be manipulated by a carefully constructed sequence of WebGPU API calls to:

  1. Control the freed memory region's contents (heap spray / type confusion)
  2. Redirect program execution to attacker-controlled code

Because WebGPU is a first-class JavaScript API accessible from any webpage, the entire attack surface is reachable through the browser's renderer process — no plugins, no downloads, no elevated permissions required.

Attack Vector

Victim visits attacker-controlled page
  └─> Page loads malicious JavaScript
        └─> JS crafts a sequence of gpuDevice.queue operations
              └─> Race condition triggers use-after-free in Dawn
                    └─> Heap spray overwrites freed memory
                          └─> Arbitrary code execution in renderer process
                                └─> Sandbox escape (chained with separate exploit)
                                      └─> Full system compromise

The exploit requires user interaction only insofar as visiting a webpage — no clicks, no downloads, no JavaScript consent dialogs. Drive-by attacks via malvertising or compromised legitimate sites are viable.

Real-World Impact

Google confirmed that "an exploit for CVE-2026-5281 exists in the wild" at the time of disclosure on April 1, 2026. CISA added the CVE to its KEV catalog the same day, citing evidence of active exploitation by threat actors targeting federal networks. Attribution has not been publicly confirmed, though the exploitation pattern (drive-by delivery, no user interaction) is consistent with sophisticated nation-state and financially motivated actors who have targeted browser zero-days throughout 2026.

This is the fourth Chrome zero-day exploited in the wild in 2026, following:

CVE Component Type Patched
CVE-2026-2441 CSSFontFeatureValuesMap Iterator Invalidation Feb 2026
CVE-2026-3909 Skia Out-of-Bounds Write Apr 2026
CVE-2026-3910 V8 JavaScript Engine Inappropriate Implementation Apr 2026
CVE-2026-5281 Dawn (WebGPU) Use-After-Free Apr 1, 2026

2. Who Is Affected?

Directly Affected Browsers

Browser Vulnerable Version Patched Version
Google Chrome (Windows/macOS) < 146.0.7680.177 146.0.7680.177 / 146.0.7680.178
Google Chrome (Linux) < 146.0.7680.177 146.0.7680.177
Microsoft Edge (Chromium-based) Corresponding Chromium builds Patch released by Microsoft
Brave Browser Chromium builds using affected Dawn Update to latest stable
Opera Chromium builds using affected Dawn Update to latest stable
Any Chromium-based browser Builds shipping the affected Dawn version Varies by vendor

Who Is NOT Affected

  • Mozilla Firefox — uses its own WebGPU implementation (wgpu), not Dawn
  • Apple Safari — uses WebKit's own WebGPU backend
  • Users with WebGPU disabled (niche enterprise hardening configurations)

Risk Factors That Amplify Exposure

  • Systems where Chrome auto-update has been disabled by policy (common in locked-down enterprise environments that ironically delay patch application)
  • Users on Extended Stable channel who receive patches on a 4-week delay
  • Kiosk and embedded deployments using Chrome in locked versions
  • Organizations allowing Shadow IT browser use where patch status is unmonitored

3. How to Detect It (Testing)

Manual Testing Steps

Step 1: Check your current Chrome version

  • Open Chrome → Navigate to chrome://settings/help
  • Note the displayed version number
  • If the version is below 146.0.7680.177, the browser is vulnerable

Step 2: Check fleet-wide browser versions

  • On Windows (via PowerShell, run on endpoint or via GPO/RMM): 
    (Get-Item "C:\Program Files\Google\Chrome\Application\chrome.exe").VersionInfo.FileVersion
  • On macOS (Terminal): 
    /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --version
  • On Linux: 
    google-chrome --version
# or
chromium-browser --version

Step 3: Verify WebGPU is enabled (determines exploitability)

  • Navigate to chrome://flags/#enable-unsafe-webgpu
  • If WebGPU is enabled (default in modern Chrome), the attack surface is active

Step 4: Check for Indicators of Compromise

  • Review endpoint security logs for unusual child processes spawned by chrome.exe or chrome (unexpected cmd.exe, powershell.exe, bash, or network tools as Chrome subprocesses)
  • Review DNS query logs for connections from Chrome to unexpected external hosts

Automated Scanning

Tool: Tenable Nessus / Tenable.io

  • Plugin ID for CVE-2026-5281 is available in the April 2026 plugin feed
  • Command: nessus -q -x -T html -c /your/policy.nessus -o output.html target_ip
  • Expected output: Flags Chrome installations below the patched version

Tool: Qualys Browser Security Module

  • Query: CVE:CVE-2026-5281 in the vulnerability management dashboard
  • Will enumerate all detected Chrome/Chromium installs and flag vulnerable versions

Tool: osquery (endpoint fleet detection)

SELECT name, version, install_location
FROM programs
WHERE name LIKE '%Chrome%'
  AND version < '146.0.7680.177';

Run via osqueryi or fleet management (Fleet, Kolide):

osqueryi "SELECT name, version FROM programs WHERE name LIKE '%Chrome%';"

Tool: Snyk / GitHub Dependabot (for apps embedding CEF/Electron)

  • If your application bundles Chromium via Electron or CEF, run: 
    snyk test --all-projects
  • Look for Chromium version references below the patched build

Code Review Checklist (for applications embedding Chromium)

  • Confirm Electron framework version ships Chromium ≥ 146.0.7680.177
  • Verify package.json / electron-builder config pins to a non-vulnerable Electron release
  • Check CEF (Chromium Embedded Framework) version if used in a native app
  • Audit any webgpu API calls in embedded browser contexts for unusual queue submission patterns
  • Review Content-Security-Policy headers to limit WebGPU context creation where not needed

4. How to Fix It (Mitigation)

Step-by-Step Remediation

For End Users:

  1. Open Chrome and navigate to chrome://settings/help
  2. Chrome will automatically check for updates — allow it to download version 146.0.7680.177 or later
  3. Click "Relaunch" to apply the update (all tabs will be restored)
  4. Confirm the version displayed is 146.0.7680.177 or higher

For Enterprise / IT Administrators:

  1. Push the update via your software management platform (SCCM, Intune, Jamf, Ansible, etc.)

    • Download the enterprise MSI/PKG from the Chrome Enterprise download page
    • Target: all endpoints regardless of department criticality
    • Priority: P1 — complete within 24–48 hours given active exploitation

  2. Verify deployment success — run fleet query to confirm no endpoints remain on vulnerable versions (use osquery above, or your UEM/EDR dashboard)

  3. Force update via Group Policy (Windows):

    Computer Configuration > Administrative Templates > Google > Google Update > 
Applications > Google Chrome > Update policy override → "Always allow updates"

    Additionally:

    Computer Configuration > Administrative Templates > Google > Google Update > 
Applications > Google Chrome > Target version prefix override → "146."

  4. Update other Chromium-based browsers — Microsoft Edge receives Chromium patches with a slight delay; check the Microsoft Edge Security Updates page and deploy the latest Edge build. Repeat for Brave, Opera, etc., per their respective update mechanisms.

  5. Communicate to users — notify employees to restart Chrome if the update notification badge appears, emphasizing urgency given active exploitation

Code Fix Example (for apps embedding Chromium via Electron)

Before (vulnerable):

// package.json — pinned to a vulnerable Electron version
{
  "dependencies": {
    "electron": "^34.0.0"
  }
}

After (patched):

// Update to the Electron release that bundles Chromium 146.0.7680.177+
{
  "dependencies": {
    "electron": "^34.5.0"
  }
}

Then:

npm update electron
npm audit

Confirm the bundled Chromium version:

node -e "const { app } = require('electron'); console.log(process.versions.chrome);"

Configuration Hardening (Short-Term Mitigations)

If immediate patching is not possible (e.g., validated rollout process, change freeze):

  1. Disable WebGPU via Chrome Enterprise Policy:

    // chrome_policy.json (deploy via GPO or MDM)
{
  "WebGPUEnabled": false
}

    This disables the Dawn component and removes the attack surface, at the cost of WebGPU-dependent features (3D web apps, certain AI inference in browser).

  2. Block access to unknown/untrusted web resources via proxy/firewall filtering — reduce drive-by exposure by enforcing web category filtering

  3. Enable Chrome Enhanced Safe Browsing via policy:

    {
  "SafeBrowsingProtectionLevel": 2
}

  4. Deploy browser isolation (if available in your security stack) — zero-trust browser isolation products (Zscaler ZIA, Menlo Security, Prisma Access Browser) can neutralize renderer-process exploits by rendering web content in a remote container

5. How to Test the Fix (Validation)

Regression Test Scenarios

  • Scenario A: Confirm Chrome reports version 146.0.7680.177 or higher at chrome://settings/help on all patched endpoints
  • Scenario B: Confirm that running the Nessus / Qualys scan post-patch returns zero findings for CVE-2026-5281 on patched hosts
  • Scenario C: Confirm that normal WebGPU-dependent web applications (e.g., Google Maps 3D, WebGPU demos at webgpufundamentals.org) still function as expected post-patch — verifying no regression in normal GPU rendering

Security Test Cases

Test Case 1: Version Verification

  • Precondition: Patch deployed to target endpoint
  • Steps: Run google-chrome --version or navigate to chrome://settings/help
  • Expected Result: Version ≥ 146.0.7680.177 displayed; Nessus plugin for CVE-2026-5281 returns "Not Vulnerable"

Test Case 2: Exploit Proof-of-Concept Blocked

  • Precondition: Patched Chrome installed; controlled test environment (never test PoC exploits on production systems)
  • Steps: Load a known-safe WebGPU stress-test harness that exercises high-frequency gpuDevice.queue.submit() concurrency patterns
  • Expected Result: No crashes, no unexpected child process spawning, no memory corruption signals in Chrome's built-in crash reporter

Test Case 3: WebGPU API Availability

  • Precondition: Patched Chrome; WebGPU enabled
  • Steps: Navigate to chrome://gpu and verify WebGPU status; run navigator.gpu.requestAdapter() in DevTools console
  • Expected Result: navigator.gpu is not null; adapter is returned successfully; rendering pipeline initializes without error

Automated Tests (CI/CD Integration)

For teams running Electron apps or web apps with WebGPU, integrate the following into your CI pipeline:

// security-audit.test.js — Jest/Playwright
const { chromium } = require('playwright');

test('Chrome version meets security baseline', async () => {
  const browser = await chromium.launch();
  const version = browser.version();
  const [major, minor, build, patch] = version.split('.').map(Number);
  
  // Patched version: 146.0.7680.177
  expect(major).toBeGreaterThanOrEqual(146);
  if (major === 146) {
    expect(build).toBeGreaterThanOrEqual(7680);
    if (build === 7680) {
      expect(patch).toBeGreaterThanOrEqual(177);
    }
  }
  
  await browser.close();
});

Run with: npx playwright install chromium && npx jest security-audit.test.js

6. Prevention & Hardening

Best Practices

  • Enable Chrome automatic updates fleet-wide — the single most impactful long-term control. Chrome zero-days in 2026 have averaged patch-to-exploitation windows measured in hours; manual update workflows are operationally insufficient. Use Google Chrome's enterprise update policies to enforce automatic updates.

  • Adopt a browser inventory and version SLA — maintain a continuously updated asset inventory of every browser installation, version, and device. Establish a policy that critical browser CVEs (CVSS ≥ 7.0, KEV-listed) must be patched within 24 hours of vendor release.

  • Apply the principle of least privilege for browser renderer processes — on Windows, configure Chrome's renderer process to run at a lower integrity level. On Linux, ensure Chrome runs with appropriate seccomp-bpf sandbox enabled (--no-sandbox must be prohibited in all deployment configs).

  • Deploy browser-based attack surface reduction — where feasible, implement endpoint policies to block navigation to uncategorized or newly registered domains, which are frequently used for drive-by exploit delivery.

  • Monitor for lateral movement following browser compromise — a renderer-process exploit is often the first stage; lateral movement and persistence follow. Tune EDR rules to flag Chrome spawning unusual child processes (cmd.exe, wscript.exe, network reconnaissance tools).

Monitoring & Detection

EDR / SIEM Detection Rules:

  1. Unusual Chrome child processes (Windows):

    Process: chrome.exe spawns → cmd.exe | powershell.exe | wscript.exe | mshta.exe | regsvr32.exe
Alert: HIGH — possible renderer exploit followed by sandbox escape

  2. Network connections from Chrome renderer to non-web ports:

    Source process: chrome.exe | chrome
Destination port: NOT (80, 443, 8080, 8443)
Alert: MEDIUM — unusual outbound from browser process

  3. WebGPU crash loops (Application Event Log / Chrome crash reporter):

    Event: Chrome crash dump generated involving Dawn / gpu_process
Frequency: > 3 times in 5 minutes
Alert: MEDIUM — possible exploitation attempts triggering instability

  4. CISA KEV alert monitoring: Subscribe to CISA's KEV RSS feed and integrate into your vulnerability management platform to receive real-time alerts when exploited vulnerabilities are cataloged — enabling immediate triage without waiting for vendor notification.

Threat Intelligence Feeds: Integrate Mandiant, Recorded Future, or VirusTotal Intelligence feeds to receive automated alerts when new Chrome exploit samples are uploaded, allowing proactive detection before widespread exploitation.

References

Latest from the blog

See all →