Chrome CVE-2026-5281: WebGPU Dawn zero-day is 2026's fourth exploited Chrome bug

On 31 March 2026 Google shipped an emergency Chrome update for CVE-2026-5281, a use-after-free in Dawn, Chromium's WebGPU implementation, and said an exploit exists in the wild. It is the fourth exploited Chrome zero-day of 2026. Updating your own browser is the easy part. Developers also ship Chromium inside Electron apps, headless test runners and scraping services, and those copies don't update themselves.

What happened

Google's stable channel update fixed CVE-2026-5281 in Chrome 146.0.7680.177/178 for Windows and macOS and 146.0.7680.177 for Linux. The NVD description says a remote attacker "who had compromised the renderer process" could execute arbitrary code via a crafted HTML page. Google confirmed that "an exploit for CVE-2026-5281 exists in the wild" but, as usual, held back details until most users have updated. Google has not said who reported the bug or who is exploiting it.

CISA added CVE-2026-5281 to its Known Exploited Vulnerabilities catalog on 1 April 2026, with a 15 April deadline for US federal civilian agencies. The three earlier exploited Chrome zero-days of 2026 were CVE-2026-2441 (a use-after-free in CSS, fixed in February) and CVE-2026-3909 and CVE-2026-3910 (fixed in March).

Who is affected

• Chrome desktop before 146.0.7680.177 (Linux) or 146.0.7680.177/178 (Windows, macOS).
• Other Chromium browsers such as Microsoft Edge, Brave, Opera and Vivaldi until they ship their own builds with the fix.
• Apps and tools that bundle Chromium: Electron and CEF desktop apps, and headless Chrome used by Puppeteer, Playwright, PDF renderers and scrapers, especially when they load untrusted pages.

What it means for developers and engineering teams

Dawn is the library that turns WebGPU calls from JavaScript into native Direct3D 12, Metal or Vulkan commands. It is large, native, performance-sensitive C++ that handles input from web content, which is the kind of code where use-after-free bugs live. In a use-after-free, code keeps using a pointer after the object it pointed to has been freed. If an attacker can put their own data in that freed memory, they can control what the program does next.

The phrase "who had compromised the renderer process" matters. It suggests CVE-2026-5281 is one link in a chain: an attacker first gets code running in the sandboxed renderer through another bug, then uses Dawn, which talks to the more privileged GPU side, to go further. Real-world Chrome exploits are almost always chains, so patching any link breaks the attack.

For teams the practical issue is copies of Chromium you forgot about:

• Electron apps include a specific Chromium version. Users stay exposed until you ship a release built on an Electron version that includes the fix.
• Headless browsers in CI and back-end services are often pinned in Docker images for months. A service that renders user-supplied URLs or HTML is effectively a browser visiting attacker pages.
• WebGPU expands the attack surface. If your product doesn't need GPU features in an embedded browser, reducing GPU access reduces exposure.
• Chromium forks lag. Edge, Brave, Opera and Vivaldi each ship the fix on their own schedule, and corporate fleets often pin browser versions for app compatibility. Track the browser version on endpoints the same way you track OS patch levels, and treat an exploited zero-day as a reason to override pins.

What to do now

1. Update and restart browsers. Check chrome://settings/help, or run google-chrome --version on Linux. On managed fleets, enforce a minimum version through browser policy and set a relaunch notification deadline.
2. Refresh headless browsers: npx playwright install chromium after upgrading Playwright, or npx @puppeteer/browsers install chrome@stable. Then rebuild any Docker images that bake in Chrome or Chromium.
3. Audit Electron apps. Log process.versions.chrome at startup, upgrade to an Electron release that includes the CVE-2026-5281 fix (check Electron's release notes), and ship an update.
4. Reduce GPU exposure where you don't need it. Electron apps that don't need GPU features can call app.disableHardwareAcceleration(). Run headless renderers with --disable-gpu, keep Chromium's sandbox on (avoid --no-sandbox), and use a low-privilege container.
5. Isolate services that render untrusted content with no access to internal networks or credentials.

Related on TechLogHub

• Tauri vs Electron: bundled Chromium vs system webview
• Playwright vs Cypress
• Selenium vs Playwright

Sources

• NVD: CVE-2026-5281
• The Hacker News: New Chrome zero-day CVE-2026-5281 under active exploitation (1 April 2026)
• Canadian Centre for Cyber Security: Google Chrome security advisory AV26-306
• HivePro: CVE-2026-5281 threat advisory