Glonce

WebGPU bug freezes M-series Macs: Apple calls it not a security issue

securityThe Glonce editorsHacker News🔥62Glonce rating62Impact50Novelty40Relevance70Surprise55Players65Credibility82

Auberon López has published a proof of concept, nicknamed "the deathray," showing that a single WebGPU shader can freeze a Mac's entire graphical interface after nothing more than a click. The trick is a compute shader containing a deliberately infinite loop: a for-loop whose counter is never incremented, so it spins forever inside the GPU while continuously overwriting a data buffer. A vertex shader that reads from that same buffer can never proceed, because the compute shader never finishes, and the resulting GPU backlog spills over into every other process that wants the GPU, including WindowServer, the process that draws macOS's own desktop. The effect is inconsistent: sometimes the mouse still moves, sometimes it does not; sometimes the screen shows a spinning beachball, sometimes patches of magenta visual corruption instead, and López says they do not know what determines which happens.

López reproduced the freeze on Chrome, Firefox and Safari on M-series MacBooks running macOS Tahoe, but not on any other operating system tested, where the same page merely freezes its own browser tab, and closing that tab restores the machine to normal. On macOS, the rest of the computer keeps working during the freeze itself, an SSH session into the machine stays usable, but a built-in Watchdog process that monitors WindowServer's responsiveness eventually triggers a kernel panic and forces a restart once WindowServer has been unresponsive for long enough. Anyone who does not want to wait for the Watchdog can force the same restart sooner by holding down the power button, though López warns that a browser which reopens the same tab on relaunch will simply trigger the deathray again.

López frames the deathray as a repeat of a 2023 bug: Ron Masas of Imperva built a similar WebGL shader called ShadyShader that hung the GPU with a large but technically finite loop, and Apple assigned it CVE-2023-40441 with a CVSS score of 6.5 (medium), then added input validation meant to catch runaway loops. López argues that validation is weaker under WebGPU: the deathray's loop has no exit condition at all and is, in their words, "trivially identifiable" as infinite, yet it still is not caught. Since detecting every infinite loop in general is impossible under the halting problem, López argues Apple instead needs better pre-emption of unresponsive shaders, particularly ones running code from an untrusted website, and notes that every other operating system tested already handles this correctly. They speculate, without stating it as fact, that part of Apple's difficulty may trace to the M-series chip architecture: the OS kernel cannot pre-empt the GPU directly, that job instead belongs to a coprocessor known as the ASC, and Apple's GPU pre-emption logic lives inside the ASC's own firmware. For more on that architecture, López points to a separate write-up by Asahi Lina.

López found the bug by accident while learning WebGPU at the Recurse Center, then disclosed it to Apple Security on 27 July 2026. Apple reproduced it quickly, said it intended to fix it, and gave López a fix timeline that López is keeping confidential. On 26 August 2026, Apple reversed course, telling López it did "not see any security implications with [my] report" and that the report would not "result in a change in [Apple's] products," forwarding it instead to another team for what Apple called "potential enhancement considerations," a phrase López reads as a sign the fix will be a low priority, if it happens at all. Apple explained its own reasoning directly: "the result is either a crash, hang, or recoverable data loss which we do not consider to be a security issue." López says the security researchers they consulted tend to agree with that framing, and admits that on a technical level Apple is not wrong, but says most non-security people they have talked to are surprised that a mere click can affect the whole machine and are surprised Apple is not prioritizing a fix. López stresses the deathray is nowhere near as severe as a sandbox escape, remote code execution or a data breach, but says its very low barrier to entry, just getting someone to click a link, still gives it the potential to be a serious nuisance, comparing it to "a meaner version of a Rickroll." They say they hope Apple fixes it eventually, explicitly asking Apple not to respond by disabling WebGPU by default, and suggest that until then, people might put the bug to playful, non-malicious use, such as a video game where losing freezes the player's Mac only if they opt in beforehand.

Key facts

  • The deathray is a WebGPU compute shader with a loop that never increments its counter, so it never exits; because a vertex shader depends on the same buffer, the freeze spreads through the GPU to WindowServer, macOS's own display process.
  • Auberon López reproduced the freeze on Chrome, Firefox and Safari on M-series MacBooks running macOS Tahoe; on the other operating systems tested, the same page only freezes its browser tab.
  • Once WindowServer stays unresponsive long enough, a built-in Watchdog triggers a kernel panic and restarts the Mac; an SSH session into the machine still works during the freeze itself.
  • López compares it to a 2023 WebGL precedent, Ron Masas's ShadyShader (CVE-2023-40441, CVSS 6.5, medium), after which Apple added runaway-loop detection that López says is weaker under WebGPU.
  • López disclosed the bug to Apple Security on 27 July 2026; Apple first said it would fix it, then on 26 August 2026 said it saw no security implications and would not change its products.

Why it matters

The deathray shows a website can still turn one click into a full Mac restart, three years after Apple treated a similar bug, ShadyShader, as serious enough to earn a CVE and a CVSS score of 6.5. WebGPU's own runaway-loop protection looks weaker than the fix Apple built for WebGL, even though López calls the loop "trivially identifiable." The freeze happens beneath the browser, inside the OS's own WindowServer and GPU stack, so it reaches Chrome, Firefox and Safari alike. No single browser vendor can patch it alone. That breaks a basic assumption most people carry about browsing: that clicking a link cannot damage anything beyond the open tab.

Who it affects

López confirmed the freeze on M-series MacBooks running macOS Tahoe, across Chrome, Firefox and Safari alike. Any website can trigger it just by loading a WebGPU shader; no plugin or special permission is needed, since WebGPU already ships on by default in current browsers. López has not tested Intel-based Macs or other Apple Silicon devices beyond MacBooks. Users on other operating systems face a much smaller version of the same problem: the browser tab hangs and the machine chugs, but closing that tab is enough to recover.

How to use it

There is no product here, only a public proof of concept. López's writeup at auberon.xyz links the exact shader source code and includes a live button that will freeze a visiting Mac, with an explicit warning attached. Apple has not shipped a fix, so the only remedy on macOS today is to avoid untrusted WebGPU demos and, if already hit, to hold down the power button rather than wait for the Watchdog's own kernel panic, keeping in mind that a browser which restores the same tab on relaunch will trigger the freeze again. López explicitly hopes Apple's eventual fix will not simply be turning WebGPU off by default, and suggests the bug could be put to playful use instead, such as an opt-in video game where losing freezes the player's own Mac.

How solid is it

The account rests on López's own technical writeup: shader source code, a working live demo, and a first-hand timeline of the exchange with Apple Security, including direct quotes from Apple's replies. The comparison to ShadyShader points to a real, independently documented precedent, CVE-2023-40441 at CVSS 6.5. What is not independently verifiable is Apple's side of the story beyond what López quotes. There is no public Apple advisory, and the deathray itself carries no CVE or severity score of its own. The freeze is confirmed only on the M-series MacBooks and three browsers López personally tested, with no independent replication cited and no data on Intel Macs or other configurations.

Risks and caveats

López is explicit that the deathray sits far below a sandbox escape, remote code execution or a data breach. It is a denial-of-service annoyance, and even the eventual kernel panic is what Apple itself calls "recoverable." Other processes, including an SSH session into the machine, keep working throughout the freeze. The real risk is nuisance at almost no cost to an attacker: triggering it needs nothing more than a link and a click, and a browser that reopens the same tab after the forced restart can put a victim right back into the same loop. Apple has told López it will not change its products over this report and has passed it to another team only for "potential enhancement considerations," which López reads as a low priority. No public fix timeline exists. The writeup also does not explain why the visible symptoms vary between a frozen cursor, a beachball and magenta screen corruption, and it does not test whether Intel-based Macs share the same exposure.

“the result is either a crash, hang, or recoverable data loss which we do not consider to be a security issue.”

— Apple, responding to the bug report