One Link, One Infinite Loop, One Frozen Mac: Meet the Deathray
Okay, I need to talk about this thing going around called the Deathray, because it might be the most delightfully unhinged security story I've read in a while.
A website can freeze your entire Mac. Not the browser tab. Not the app. The whole machine — beachball and all — until it either restarts itself or you hold the power button like it's 2004 again.
I know, every few months something "freezes your device" makes the rounds and turns out to just be a browser tab choking, which, fine, annoying, but not exactly headline material. This one's different, and once you see how it works, it's hard not to be a little impressed and a little unsettled at the same time.
The short version
The Deathray is a little demo page built by developer Auberon López, who stumbled into it — as one does — while teaching themselves WebGPU at the Recurse Center.
They wrote a loop that never ends, expected a browser tab to choke on it the usual way, and instead watched their whole Mac lock up. Naturally, the next question was "does it do that every time?" It does.
López has confirmed it on M-series MacBooks running macOS Tahoe, and it does the exact same thing in Chrome, Firefox, and Safari. That's the detail that makes this interesting — when something breaks the same way in three completely different browsers, that tells you the problem isn't really in the browser. It's sitting in macOS itself.
Nobody's totally sure yet whether it hits other Macs or older versions of macOS — López is asking people to test it and report back.
And yes, there's a live version you can try. I'll repeat what López says, because it's worth repeating: clicking that button really will freeze your Mac. Don't do it unless you're genuinely fine rebooting.
What is WebGPU, and why does it matter here
Quick primer, because this only works because of a technology most people have never heard of. WebGPU is a fairly new feature built into browsers — it lets a website talk directly to your computer's graphics chip, the GPU, and hand it small programs called "shaders" to run, whether that's drawing something on screen or just crunching numbers fast.
It's the modern standard now, built into every major browser. This isn't some obscure corner of the web nobody touches, which is exactly why a bug hiding inside it is worth caring about.
How the freeze actually happens
Here's the clever (evil?) part. WebGPU lets you link two of these shader programs together: one that crunches numbers, and one that draws to the screen — and have them both reading and writing the same little piece of memory on the GPU. Write the number-crunching one so it never finishes — just loop forever, on purpose — and the drawing one, waiting on that output, stalls right along with it. Forever.
On most computers, the operating system can just step in and shut down a graphics task that's stuck, the same way it can force-quit a program that's hogging your processor. Apple's M-series chips don't work like that, though. The core of macOS doesn't talk to the graphics chip directly — there's a separate little chip in between that handles all the graphics scheduling, and the logic for stopping a stuck task lives on that chip, not inside macOS itself. (If you want to go deeper on that setup, Asahi Lina's write-up on the M1 GPU is genuinely excellent.)
So when a shader gets stuck badly enough, the jam doesn't stay contained. It backs up into everything else competing for the GPU, including WindowServer — the part of macOS that draws your entire desktop. Once WindowServer stops responding, you get some flavor of frozen screen: sometimes the cursor still moves, sometimes the display just fills with garbled color — it seems to vary.
Weirdly, everything else on the machine keeps working fine underneath — you can even log into it remotely from another computer while your own screen is stuck. But macOS runs a watchdog program that checks in on WindowServer, and if WindowServer goes quiet for too long, the watchdog assumes something's badly wrong and forces the whole computer to restart. Apple calls that a "kernel panic," which is really just a fancy name for "everything crashed at once." If you're too impatient to wait for that, the power button still works — just hope your browser doesn't helpfully reopen the same tab when it comes back.
It's not perfectly consistent, either. Early reactions to López's post showed the same spread — some people got the full desktop lockup, others just had their browser hang while the rest of the system stayed fine. Same bug, different machine, apparently.
This isn't the first time
This also isn't Apple's first rodeo with a bug like this. Back in 2023, security researcher Ron Masas at Imperva found something similar called ShadyShader, using WebGL instead of WebGPU to cause the same kind of GPU pileup. Apple took that one seriously — they gave it an official vulnerability number, CVE-2023-40441, rated medium severity, and added checks meant to catch runaway loops before they could run.
Whatever those checks were doing, they didn't carry over to WebGPU — the loop at the center of the Deathray is, by López's own account, easy to spot just by looking at the code. Though honestly, catching every possible infinite loop ahead of time is a fight nobody can fully win — there's a whole area of computer science about why you can never perfectly predict whether a program will get stuck. The fix that would actually hold up is being able to stop a stuck shader after it's already running, and that's exactly the part Apple's chips currently aren't good at.
Reporting it, and Apple's response
This is the part of the story that got me, honestly. López reported this to Apple Security in late July 2026. Apple reproduced it fast and said they planned to fix it, timeline kept confidential. Reasonable so far.
Then, a month later, the tune changed: Apple came back saying they didn't see any security implications and didn't expect it to change their products, and passed the report along to a team that handles general "enhancement" ideas instead — which López reads as basically meaning "this isn't getting fixed anytime soon."
That's a notably different call than the one they made on ShadyShader. And apparently, the security researchers López talked to mostly agree with Apple's technical read here. I get the logic. I still think it's a little bit nuts in practice.
Why it still feels like a big deal
Here's the thing about trust and browsers: most people don't think about it in these words, but they act like clicking a link is safe. Worst case, some annoying pop-ups, maybe a scammy page you close right away.
Nobody expects clicking a link to take down their whole computer. The Deathray breaks that assumption in a really visible way. And on paper, López and Apple are both right that it's nowhere near as serious as a sandbox escape, remote code execution, or an actual data breach — nothing is stolen, nothing is touched, the worst case is a forced reboot and a bad ten minutes. Apple's security line sits right at that point: no theft, no security issue.
But try explaining that distinction to someone whose Mac just went black mid-sentence. That gap — "barely a security issue" on paper, "deeply alarming" in practice — is honestly the most interesting part of this whole story. It's the same gap that made old-school prank crashes and denial-of-service tricks memorable long after anyone took them seriously as real threats.
Call it a meaner Rickroll: same one-click delivery, dressed up in genuinely cool graphics-chip trivia.
Where it stands
Everything's public. López has posted the underlying source code right alongside the write-up, and seems more amused than anything — hoping people find playful, consensual ways to use it.
A video game where losing freezes your machine, with your permission first, sounds like a genuinely fun idea. Meanwhile the actual fix, if it ever comes, is apparently sitting in a queue somewhere at Apple.
My honestly mundane takeaway: be a little more careful about what links you click from places you don't trust. And if your Mac ever does something like this out of nowhere — you're not losing it. There's a decent chance it's exactly this.
Sources: Auberon López's original write-up and its Hacker News discussion.
Comments (0)
Login to post a comment.