CVE-2026-5281

What it actually does

CVE-2026-5281 is a use-after-free vulnerability in Dawn, Chromium's WebGPU implementation, affecting Google Chrome prior to 146.0.7680.178. If an attacker can convince a user to open a crafted HTML page, and the attacker has already achieved renderer-process compromise or can chain this flaw with a renderer bug, the vulnerability can be used to execute arbitrary code in the browser context. Because the CVSS vector indicates no privileges required, low attack complexity, network reachability, and user interaction, successful exploitation can compromise confidentiality, integrity, and availability of data accessible to the browser process. The issue is listed in CISA KEV, has active in-the-wild exploitation, and should be treated as an urgent browser compromise risk.

Why it matters to the business

Successful exploitation can allow an attacker to take control of a user's browser session, steal sensitive data handled through the browser, manipulate web content or sessions, deploy additional malware, or use the endpoint as a foothold for broader intrusion. Because Chrome is widely deployed across Windows, macOS, and Linux environments, exposure can be broad and operationally disruptive if browser patching is delayed. CISA KEV status and an April 15, 2026 remediation deadline indicate that exploitation is confirmed and that regulated or government-facing organizations should prioritize remediation immediately, even though the EPSS score is moderate.

How an attack unfolds

An attacker hosts or injects a malicious HTML page that exercises vulnerable Dawn/WebGPU behavior in Chrome. The victim must browse to the page, often through phishing, malvertising, watering-hole compromise, or a link embedded in a legitimate-looking workflow. The vulnerability requires that the attacker has compromised the renderer process or chains this bug with another renderer vulnerability, after which the use-after-free condition is triggered to corrupt memory and execute attacker-controlled code. In real intrusions, this type of browser exploit is commonly used as an initial access or payload-delivery mechanism: the attacker obtains code execution in the browser process, attempts to escape or abuse the browser sandbox through additional techniques, harvests browser-accessible data such as session tokens or credentials, and then deploys follow-on tooling. Reported active exploitation and the associated threat context, including BlueHammer, make this a priority for patch validation and retrospective hunting.

How to fix it

Upgrade Google Chrome to version 146.0.7680.178 or later on all supported platforms. Where Chrome is managed centrally, force an update and browser restart because Chrome patches are not fully effective until the running browser process is replaced. Apply corresponding Chromium-based browser updates if the same Dawn/WebGPU code is inherited by downstream products. If immediate patching is not possible, reduce exposure by disabling or restricting WebGPU where operationally feasible, using enterprise browser policies to limit access to untrusted sites, isolating high-risk browsing in remote browser isolation or hardened virtual environments, and blocking known malicious delivery infrastructure as it becomes available. These mitigations should be considered temporary; patching remains the primary fix.

How to confirm the fix worked

Confirm Chrome reports version 146.0.7680.178 or later on every endpoint and that users have restarted the browser after update. Validate enterprise browser-management telemetry, endpoint inventory, vulnerability scanner results, and software asset data for all Windows, macOS, and Linux systems. On managed Chrome, verify update policy enforcement and that no devices are pinned to an older channel or blocked from auto-update. For exposure testing, safely inventory browser versions rather than attempting exploit reproduction. For mitigation validation, confirm WebGPU restriction policies, if used, are applied and effective, and confirm that no unsupported Chromium builds remain in use.

Typical attack path

1. Identify users running Google Chrome earlier than 146.0.7680.178 on Windows, macOS, or Linux.
2. Deliver a malicious URL through phishing, malvertising, compromised websites, watering-hole pages, or injected third-party content.
3. Convince the user to open the crafted page in vulnerable Chrome.
4. Trigger Dawn/WebGPU memory misuse from crafted HTML or JavaScript content.
5. Chain with or leverage an existing renderer compromise to execute arbitrary code in the browser context.
6. Attempt browser sandbox escape, credential/session theft, malware delivery, persistence, or lateral movement depending on the attacker's objective.

How to detect it

Retrospective detection should focus on signs of browser exploitation rather than a single definitive indicator, because crafted-page memory corruption exploits often leave limited on-disk artifacts. Review EDR, browser crash telemetry, proxy/DNS logs, Windows Event Logs, macOS Unified Logs, Linux syslog/journald, and endpoint process telemetry for the period before remediation. Look for Chrome renderer or GPU process crashes followed closely by unusual child processes, downloads, script execution, credential-access behavior, or outbound connections to unfamiliar domains. Useful artifacts include repeated EXCEPTION_ACCESS_VIOLATION or SIGSEGV events involving Chrome renderer/GPU processes, GPU-process instability around WebGPU/Dawn activity, and command interpreters spawned by Chrome. Proxy and DNS logs should be reviewed for visits to suspicious newly registered domains, compromised sites, malvertising redirects, or pages delivered immediately before Chrome crashes. If threat-intelligence reporting references BlueHammer infrastructure or campaign-specific domains, add those indicators to SIEM, EDR, DNS, and proxy searches. Absence of a crash does not prove absence of exploitation, particularly if the exploit chain is reliable or logs have aged out.

• Google Chrome 145.
• Chrome/145.
• chrome.exe --type=renderer
• chrome.exe --type=gpu-process
• Google Chrome Helper (Renderer)
• Google Chrome Helper (GPU)
• EXCEPTION_ACCESS_VIOLATION
• STATUS_ACCESS_VIOLATION
• SIGSEGV
• Segmentation fault
• GPU process exited unexpectedly
• Renderer process crashed
• Aw, Snap!
• Dawn
• WebGPU
• navigator.gpu
• chrome.exe spawning powershell.exe
• chrome.exe spawning cmd.exe
• chrome.exe spawning wscript.exe
• chrome.exe spawning cscript.exe
• chrome.exe spawning mshta.exe
• chrome.exe spawning rundll32.exe
• chrome.exe spawning regsvr32.exe
• Google Chrome Helper spawning sh
• Google Chrome Helper spawning bash

What your security team should do

• Treat this as an emergency browser patch because it is in CISA KEV and has active in-the-wild exploitation; complete remediation no later than the KEV due date of 2026-04-15 where applicable.
• Prioritize internet-facing, high-risk, executive, developer, helpdesk, finance, and privileged-user workstations for immediate Chrome update and restart.
• Inventory all Chrome installations across Windows, macOS, and Linux and flag any version earlier than 146.0.7680.178.
• Force browser relaunch after update through enterprise management controls to remove vulnerable running processes.
• Review EDR and browser telemetry for suspicious Chrome renderer or GPU process crashes, unusual child processes spawned from Chrome, and browsing to suspicious or newly registered domains around the exploitation window.
• Temporarily disable or restrict WebGPU for populations that cannot be patched immediately.
• Hunt for activity associated with reported exploitation context, including BlueHammer, while recognizing that public, stable exploit-specific indicators may be limited.
• Block or investigate unexpected process creation from Chrome, especially scripting shells, command interpreters, downloaders, archive tools, or persistence utilities.
• Reassess patch compliance continuously until no vulnerable Chrome versions remain.