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
| Question | Answer |
|---|---|
| What triggers it? | Loading a page with a specific WebGPU compute shader — no click-through, no permission prompt |
| What's the impact? | GPU pipeline hangs; macOS's WindowServer becomes unresponsive; a watchdog can force a kernel panic and restart |
| Which platforms? | Reproduces on Chrome, Firefox, and Safari on Apple Silicon Macs; does not reproduce the same way on other OSes tested |
| Is it patched? | No. Apple told the researcher on 2026-08-26 it does not consider this a security issue |
| Does Beam catch this? | No — it's a browser-engine/GPU-scheduling issue, not a skill or MCP config pattern |
| What should agent operators do? | Isolate browser automation that visits untrusted URLs; don't run it on the primary workstation |
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.
Who is affected, as far as anyone knows
The scope in López's own write-up of the Deathray, dated September 10, 2026, is narrow and he says so. He reproduced it on macOS in Chrome, Firefox and Safari, and not on other operating systems, where the tab freezes and the machine chugs but closing the tab recovers. He tested only M-series MacBooks running Tahoe, and asked whether other Macs were affected. An edit dated September 11 adds what Hacker News readers had reported: Max-class M-series chips were less likely to freeze fully, and Intel Macs seemed less susceptible, though "there can still be problems."
Commenters' reports in the Hacker News thread fit that picture and show how much it varies. One reports the shader froze a Mac Studio with an M2 Ultra but that the mouse still worked and force-quitting Safari restored everything (splittydev). Another, on an M4 Max under macOS Sequoia, reports the browser froze and the GPU sat at full load, but the rest of the system stayed usable and quitting the browser fixed it (inventor7777). The useful reading is that results depend on chip, OS and browser, so treat any Mac that runs agent browsing as potentially affected until you have tested it on a spare machine.
The part that matters for unattended runs: the crash loop
López ends the mechanism section with a warning: "Just hope that your browser doesn't automatically reopen the same tab when it starts up again." Browser session restore is what turns a one-time freeze into a repeat one. One HN commenter reports that their Mac reopened its windows after the restart, loaded the page again, and needed a second restart (eliwang). Another found their browser was configured to restore tabs and hit the same thing (isolay).
This is not new with WebGPU. Imperva's write-up of ShadyShader, ShadyShader: Crashing Apple Devices with a Single Click, describes the same loop as a "recursive DoS": after the device reboots, the browser reopens previous tabs, the malicious page loads again from the cache, and the machine crashes again. Imperva's advice for a user stuck in the loop was to disable JavaScript before opening the browser.
For an agent, the equivalent is a persistent browser profile. If an automation setup keeps one profile across runs, restores the last session, and starts unattended, then a single bad page can leave the machine failing every time the job restarts, with nobody at the keyboard. A fresh, disposable profile for each run avoids that by design.
Precedent: ShadyShader and the 2023 CVE
López's post places the Deathray next to Imperva's earlier ShadyShader, which used WebGL. According to Imperva, Apple assigned CVE-2023-40441 and fixed it "with improved input validation for the GPU drivers." The National Vulnerability Database entry says the issue was fixed in iOS 17, iPadOS 17 and macOS Sonoma 14 and that "processing web content may lead to a denial-of-service." Its CVSS 3.1 score is 6.5 (medium), with network attack vector, low complexity, no privileges, user interaction required, and no confidentiality or integrity impact. Availability impact is rated high.
The two shaders attack the same weakness differently. Imperva says modern GPUs "are proficient at detecting and stopping obvious infinite loops," so ShadyShader used deeply nested loops that are finite but enormous, which drivers cannot tell from heavy legitimate rendering. The Deathray does the opposite: its compute shader has a plain infinite loop, and López argues that the validation Apple added after 2023 appears weaker in WebGPU. Imperva also gives timing: on macOS, if WindowServer does not respond within 120 seconds the watchdog triggers a kernel panic, and in its tests MacBooks rebooted within one to two minutes.
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.
Apple's position and the argument over it
López disclosed the issue to Apple Security on July 27, 2026. He says Apple reproduced it quickly and stated it intended to fix it, with a confidential timeline. On August 26 Apple changed course. He quotes the message as saying it did "not see any security implications" with his report, that it did not "result in a change in [Apple's] products," and that it would go to another team for "potential enhancement considerations." He also quotes Apple's reasoning: "the result is either a crash, hang, or recoverable data loss which we do not consider to be a security issue."
López does not dispute that on technical grounds. He writes that security researchers he has spoken to tend to agree with Apple, but that most non-security people are surprised, because there is "a pretty strong trust in the browser" that clicking a link will not affect the rest of the computer. He also notes that Apple treated ShadyShader as a medium-severity issue, and says he hopes the fix is not to disable WebGPU by default. As of our check on October 20, 2026, we found no report of a fix or a macOS update that addresses it.
For a risk register, both positions can hold. This is a denial of service with no reported path to data. It is also a one-link way to take down a machine that is meant to run on its own.
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
- 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.
- Turn off WebGPU in automation-only browser profiles that don't need it. Firefox exposes
dom.webgpu.enabled; check your Chromium-based browser's documentation for the equivalent. If the automation task is text extraction or form-filling, it rarely needs a compute shader API at all. - Use a fresh profile for each run and disable session restore. If the machine reboots mid-job, the browser should not reopen the page that caused it.
- Put a supervisor outside the browser. López notes the rest of the machine keeps running, and SSH access stays available, while the display is hung. A watchdog process that kills the browser after a task timeout, or a runner that can be restarted remotely, is our suggestion rather than a tested fix, but it follows from that observation.
- 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.
- 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.
What developers are saying
The Hacker News thread had 192 comments. These are the commenters' own reports and views, paraphrased.
- Several argued the severity is low. achierius is not surprised it was not treated as a security issue, since a denial of service gives no direct path to secrets, though they call it egregious. socalgal2 says the problem has existed since WebGL shipped in 2011, that it is self-correcting because users stop visiting a site that freezes their machine, and that Windows and Linux added GPU monitors that reset the GPU after a long-running command. hbroom answers that this assumes users connect the freeze to the site, when most restart and reopen the same tab.
- On cause, wzdd reports that this class of lock-up predates M-series chips, recalling a similar OpenCL kernel locking an Intel MacBook where a comparable CUDA kernel on Linux was stopped after a short time.
- tetrahedon says there are more such hangs in WebGPU, some working on iOS, which they reported to Apple and had closed as not security-relevant.
- On mitigation, xoa reports having set
dom.webgpu.enabledto false in Firefox, along withpdfjs.enableWebGPU, and notes Firefox also has adom.webgpu.blocked-domainssetting.
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
- Browser AI chat risk: what Beam Sentinel checks before you send — pre-send checks on chat UIs, separate from GPU or URL-automation DoS
- 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
- AI agent web and transport security — the browser and TLS surface an agent touches, beyond this one GPU bug
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.