The Deathray: a WebGPU bug that freezes Macs

A WebGPU shader with a single infinite loop can hang a Mac's GPU badly enough to force a kernel panic and restart — cross-browser, from one click, with no vulnerable dependency or social engineering required. Security researcher Auberon López disclosed the bug, nicknamed "the Deathray," after tripping over it by accident while learning WebGPU. Apple's security team reproduced it, then decided it isn't a security issue. For anyone running AI agents that browse the open web on their own, that's worth a second look — not because it's exotic, but because "visit this URL" is exactly the kind of instruction an agent executes without a human looking at the page first.

TL;DR

How the Deathray actually works

The mechanism is small enough to fit in one file. A WebGPU compute shader runs a busy loop that never terminates:

@group(0) @binding(0) var<storage, read_write> data : array<vec4f>;

@compute @workgroup_size(1) fn compute() {
  for(var i = 0u; i < 1;) {
    data[i+1] = data[i]; // no i++, loop spins endlessly
  }
}

A vertex shader reads from the same buffer the compute shader is writing to, so it blocks waiting on that infinite loop to finish — which it never does. Per López's writeup, this backs up the GPU's work queue enough that other processes wanting the GPU, including macOS's WindowServer, get starved too. The observed symptoms vary — beachballing, an unresponsive mouse, garbled screen regions — but the rest of the machine keeps running; SSH access stays available even while the display is stuck. macOS runs a watchdog on WindowServer, and when it stays unresponsive long enough, the watchdog forces a kernel panic and restart.

This isn't the first time a browser shader has done this to Apple hardware. In 2023, Imperva's Ron Masas found a similar WebGL-based hang called ShadyShader, which Apple assigned CVE-2023-40441 with a 6.5 (medium) CVSS score and mitigated with better runaway-loop detection. The Deathray's loop is more trivially identifiable than ShadyShader's, which suggests the detection Apple shipped for WebGL didn't carry over cleanly to WebGPU — and, as López notes, loop detection is a losing game against the halting problem regardless. The fix that actually holds is pre-emption: the ability to interrupt a shader that's overstayed its welcome, the way every general-purpose OS scheduler pre-empts a runaway CPU thread.

Why this lands differently for agent operators

Most people encounter risky web content because they clicked something. An agent with browser tools — computer-use, headless Playwright/Puppeteer automation, a "follow this link" step inside a larger task — visits URLs as part of executing instructions, sometimes URLs it chose itself while following references in a page it already fetched. Nobody previews each of those pages first; that's the entire point of automating the step.

That changes the threat model for a bug like this. It doesn't need a phishing pretext or a convincing lure — a page just needs to load. If an agent's browsing surface includes attacker-influenced content (a page an attacker controls, or content injected into a page the agent was told to read), rendering it is sufficient. The result isn't data exposure; it's the machine running the agent going unresponsive or restarting mid-task, which is its own operational cost for anything unattended — a CI job, a long-running agent loop, a scheduled crawl.

It's also a different category from prompt injection, worth naming precisely: prompt injection manipulates what the agent decides to do by feeding it text; the Deathray doesn't care what the agent decides — it exploits the browser engine and GPU scheduler the instant the page renders, independent of any instruction-following the model does. Treating "the agent can open arbitrary URLs" as untrusted execution surface — not just untrusted text — is the mental model that catches both.

What Beam does and doesn't catch here

Worth stating plainly, per Beam's own scope: Beam's scanner checks skill files and MCP configs against 11 heuristic patterns — credential delivery, destructive commands, downloaded-and-executed code — before you run them. That's a static, pre-execution pass over configuration text. A GPU-scheduling bug triggered by rendering a page isn't a pattern in a skill or MCP config; it's a runtime browser-engine issue, and it's out of scope for what Beam's heuristics look at today. This is the same honesty-about-limitations principle covered in what is AI agent monitoring and the MCP security guide: a heuristic scanner catches known shapes in files it can read, not every way an agent's tools can be turned against the machine running it.

What to actually do about it

1. Isolate browser automation from your primary workstation. If an agent (or a headless automation script an agent drives) can navigate to URLs nobody reviewed, run it in a VM or disposable container, not the machine you also use for everything else.
2. Turn off WebGPU in automation-only browser profiles that don't need it — Firefox exposes dom.webgpu.enabled; Chromium-based browsers have equivalent flags. If the automation task is text extraction or form-filling, it rarely needs a compute shader API at all.
3. Treat "fetch and render this URL" as untrusted execution, not just untrusted text — the same category of risk as running an unreviewed script, distinct from prompt-injection risk covered elsewhere in agent security writing.
4. Expect no near-term patch. Apple's 2026-08-26 response classified this as non-security, so operational mitigation, not a vendor fix, is the realistic path for now.

Frequently asked questions

What is the WebGPU "Deathray" vulnerability?

A proof-of-concept discovered by security researcher Auberon López: a WebGPU compute shader with an infinite loop shares a data buffer with a vertex shader, backing up the GPU work queue indefinitely. On macOS this starves WindowServer of GPU time, and a watchdog can force a kernel panic and restart. It reproduces on Chrome, Firefox, and Safari on Apple Silicon Macs.

Does Beam detect or block the Deathray?

No. Beam's scanner checks skill files and MCP configs against 11 heuristic patterns before they run — this is a browser-engine and OS-level GPU-scheduling issue, not a pattern in a skill or MCP config, so it's outside current scope.

Why does this matter for AI agents specifically?

Agents with browser tools navigate to URLs nobody manually reviewed first, as a routine part of executing a task. A page like this needs only to be loaded — no vulnerable dependency, no social engineering — which makes agent-driven URL navigation a denial-of-service surface on whatever machine is running the agent.

Is this a data-exposure risk or a denial-of-service risk?

Denial-of-service only, per both the researcher's writeup and Apple's own assessment. There's no indication it reads memory, escapes the browser sandbox, or exfiltrates anything.

What did Apple say when this was reported?

Apple reproduced the bug after a July 27, 2026 disclosure and initially planned a fix, then reversed on August 26, 2026, stating it saw no security implications and that the report would not change their products.

Related reading

• The Deathray: a simple way for an untrusted site to freeze a Mac — the original disclosure, by Auberon López
• CVE-2023-40441 (ShadyShader) — the earlier WebGL precedent Apple assigned a 6.5 CVSS score
• What is AI agent monitoring?
• MCP security: a practical guide to tool poisoning and rug pulls
• AI agent security incidents: a timeline

This post reflects the Deathray disclosure as described by Auberon López as of publication, including Apple's August 26, 2026 response. The bug is unpatched at the time of writing; details may change if Apple revises its position.