2026年9月10日，一个不受信任网站借助网页图形接口（WebGPU）着色器可挂起苹果电脑（Mac）图形，桌面界面不可用直至强制重启，受害者仅点击链接即可。该问题在苹果操作系统（MacOS）的谷歌浏览器（Chrome）、火狐浏览器（Firefox）与苹果浏览器（Safari）复现，其他系统无此现象。仅在运行塔霍（Tahoe）的M系列苹果电脑（Macbook）测试。此技术提供浏览器内接口让网站向图形处理器（GPU）提交着色器以替代网页图形库（WebGL）。

死亡射线

一个让不受信任的网站冻住 Mac 的简单方法

2026 年 9 月 10 日

TL;DR

不受信任的网站上的一个 WebGPU 着色器就能卡住 Mac 的图形系统，桌面 UI 无法使用，直到强制重启。受害者只需要点一个链接。这个问题在 macOS 上跨浏览器复现，其他操作系统上不会。

来试试死亡射线！

下面这个按钮会冻住你的 Mac。在其他操作系统上它可能只是拖慢速度。

在我测试过的其他系统上，它会让标签页卡住、整体变得很卡，但关掉标签页就没事了。不过你的情况可能不同！只有在你愿意让电脑冻住时才点上面这个按钮。

影响范围

我在 macOS 上的 Chrome、Firefox 和 Safari 都复现了死亡射线。其他操作系统没有复现。我只在运行 Tahoe 的 M 系列 MacBook 上试过；其他 Mac 是否受影响，我很想知道。

它是怎么工作的？

死亡射线用了一项比较新的 Web 技术：WebGPU。WebGPU 提供浏览器内置 API，网站可以用它把着色器提交到设备 GPU 上运行。它意在取代 WebGL，在大多数操作系统的主要浏览器上都已支持。

整个死亡射线就是一个小文件，可以看源码。文件大部分是脚手架，关键部分是两个 WebGPU 着色器。

计算着色器里是一个无限忙等循环：循环变量不递增，所以永远出不来，只是在缓冲区里一遍遍复制同一个向量。

渲染着色器则从计算着色器正在写入的同一个缓冲区里读取数据。因为计算着色器在忙等，顶点着色器无法推进。

这溢出到了其他想用 GPU 的进程，尤其是 WindowServer。于是 WindowServer 也变得无响应。表现并不总是一样：有时我还能移动鼠标，有时不能；有时出现沙滩球，有时屏幕某块出现洋红色杂块。我也说不清是什么导致不同的表现。

有意思的是，此时电脑的其他部分还是正常的，可以正常 SSH 登录。但有个看门狗在检查 WindowServer，它长时间不响应就会触发内核恐慌，电脑随之重启。如果你中了死亡射线又不耐烦，可以长按电源键关机重启，不用等看门狗。只求浏览器重启后不要自动打开同一个标签页 :)

先例

这其实不是 Apple 第一次遇到这个问题。2023 年，Imperva 的 Ron Masas 用 WebGL 做出过一个类似的恶意着色器，名叫 ShadyShader。ShadyShader 同样用失控循环霸占 GPU，构造出技术上并非无限的巨大嵌套循环。

Apple 的回应是发布 CVE-2023-40441，CVSS 评分 6.5（中危）。为缓解问题，Apple 加强了输入验证，以便更好地检测失控循环。

那套输入验证在 WebGPU 里似乎更弱——死亡射线里的无限循环一眼就能辨认出来。但检测无限循环终究是场必输的游戏，绕不开停机问题。需要对无响应的着色器做更好的抢占，尤其当这些着色器运行的是不可信代码时。我测试过死亡射线的其他操作系统都做对了。

我怀疑 Apple 修这类问题的一部分困难来自 M 系列芯片的架构。操作系统内核无法直接抢占 GPU，GPU 由名为 ASC 的协处理器处理，内核与它通信。所有 GPU 抢占逻辑都住在 ASC 固件里。Asahi Lina 有一篇很好的文章，更详细地探讨了 M 系列 GPU 的架构。

死亡射线是怎么被发现的？

老办法：意外。我在 Recurse Center 学 WebGPU 时不小心写出了一个无限循环。它把我的电脑卡住，我很惊讶，当然就问了句「每次都这样吗？」结果确实每次都这样！我不可能是第一个撞上它的人。

披露

问题于 2026 年 7 月 27 日披露给 Apple 安全团队。Apple 很快复现，并表示打算修复。他们给了一个修复时间表，但标记为机密，所以我不会写在这里。

然而 2026 年 8 月 26 日，Apple 改变了说法，称他们「没有看到这份报告有任何安全影响」，报告也没有「导致 Apple 产品的改变」。他们说报告会被转给另一个团队做「潜在的增强考虑」。对我来说，这听起来是优先级极低的修复，如果有朝一日会修的话。考虑到 ShadyShader 被定为 6.5 中危，这有点奇怪。

话虽如此，关于什么才算安全问题，倒是有一场有趣的讨论。和我聊过的安全研究人员大多同意 Apple。按 Apple 的说法，「结果是崩溃、挂起或可恢复的数据丢失，我们不认为这是安全问题。」从技术层面讲，我不觉得他们错了。

但和我聊过的非安全人士大多对这个定性感到意外，也对 Apple 不优先修复感到意外。大多数人相当信任浏览器，有一种（也许错位的）信念：点一个链接不会对电脑的其他部分产生负面影响，顶多慢一点，直到关掉标签页。死亡射线这种东西以非常直观的方式打破了这份信任，我认为多数用户会把它看成安全问题。

我希望看到什么

死亡射线当然远没有沙箱逃逸、RCE 或数据泄露那么严重。但它的门槛极低（只要让人点个链接），所以可能相当烦人。如果被恶意使用，我把它看作更恶劣版的 Rickroll，希望 Apple 不要太久就把它修掉。（还有 Apple，别把默认禁用 WebGPU 当作修复方案！我已经爱上 WebGPU 了 💚）

但在 Apple 修好之前，我希望大家以非恶意的方式拿它找点乐子。我很想看到死亡射线游戏：输了就冻住你的 Mac（用户事先同意）。一种温和得多的「你在游戏里死了，你在现实里也死了」。

社区实测该 WebGPU 无限循环代码可跨平台导致浏览器或系统冻结，分歧主轴在于应将其视为可遭滥用的安全威胁，还是仅属不直接泄密的传统拒绝服务漏洞；同时部分用户忧虑浏览器正过度暴露硬件攻击面，也有人好奇想点却不敢。

认为“崩溃电脑”可作为胁迫用户的强大安全威胁

• 指出此类崩溃可被网页用来强制交互，如假借感染警告限时点击，或逼迫关闭广告拦截、强制关注，本质上构成拒绝服务性质的安全问题（认可度：少数人） > 把崩溃电脑当作构建块似乎足够强大，以至于成了安全问题，拒绝服务难道不算安全范畴了吗？（@sgentle）

认为这仅是拒绝服务漏洞，未直接泄密故不惊讶未被列安全事件

• 表示拒绝服务虽糟糕但不提供窃取秘密或劫持身份的直接路径，期望厂商修复但并不视为典型安全漏洞（认可度：少数人） > 拒绝服务不好，但终究没给你窃取机密或劫持身份的直接途径，不惊讶没被当安全issue（@achierius）

担忧浏览器厂商过度暴露硬件攻击面

• 批评以 Google 为代表急于把浏览器变成“系统之上的系统”，主动扩大硬件调用面，已有用户为安全在 Firefox 中禁用 WebGPU 与 WebGL（认可度：少数人）

实测多平台冻结与系统退化，但部分平台免疫或可规避

• 较多人报告在 Apple Silicon Mac、Windows 工作机、Android 手机上触发卡死或图形异常，有人重启后再次自动打开仍中招；但也有人靠强制退出恢复，iOS 27 被指零影响，Linux 上因功能实验性而未执行（认可度：较多人） > 运行任何显著 GPU 负载后整个系统开始极慢直至重启，哪怕相关进程树早已彻底终止多日（@LoganDark）

想点击体验但出于畏惧作罢

• 有用户表达对该崩溃页面的强烈好奇，却终究不敢亲自触发（认可度：少数人） > 我非常想点它，但实在做不到（@slicendice）

有价值的补充

• 曾有一名日本学生展示用简单方式令浏览器无限循环引发问题，结果遭到逮捕（@hyperhello）
• Metal 基于 C++14，可在着色器里写 Duff's Device，导致编译器各种严重故障，但从未真正内核崩溃（@StilesCrisis）
• 不同于 CPU 由内核调度器多路复用，GPU 是否以同样方式复用从而避免锁死其他程序，仍存技术疑问（@krackers）