The Deathray: A simple way for an untrusted site to freeze a Mac

Original Article ↗ Hacker News Discussion ↗

A newly highlighted WebGPU exploit can reliably freeze macOS machines—and some Android devices—simply by visiting a specially crafted webpage, in some cases forcing hard reboots and repeated lockups when browsers auto-restore tabs. Commenters debate whether this kind of denial-of-service should be treated as a serious security vulnerability, noting potential for ransomware-style scams, data loss, and harm to non-technical users who can’t easily identify the cause. The incident also fuels broader criticism of exposing ever more GPU and hardware features to the web, pitting performance and rich web apps against increased attack surface and system instability.

Observed behavior and severity

  • Many macOS users report full system hangs: cursor may move but UI, Force Quit, and input are unresponsive; often requires a hard power-off.
  • On some Macs it only kills Safari or the tab; quitting the browser immediately restores normal operation.
  • A few extreme reports: repeated crashes on login due to auto-restored tabs; one user initially couldn’t boot even in safe mode and needed an update/reinstall before recovery.
  • Non-mac behavior is mixed:
    • Some Windows browsers just freeze the tab or all tabs briefly, then kill the offending page.
    • Some Android devices (e.g., Pixel, Samsung) reportedly hard-freeze; others with different browsers or hardened OS builds only see brief stutters or nothing.
    • Linux/Firefox cases range from a single crashed browser to no visible impact.
  • iOS is reported as unaffected; macOS 27 RC still impacted.

Security and threat model debate (DoS)

  • Strong concern that a reliable browser-triggered freeze is a meaningful denial-of-service and thus a security issue.
  • Suggested abuse cases: scareware (“your computer froze due to a virus”), ransom-style “we’ll keep freezing you unless…”, ad-tech coercion (“disable adblock or we crash your machine”), more believable fake-AV scams because the machine really did freeze.
  • Others argue it’s “only availability,” no data theft or privilege escalation, so lower priority.
  • Disagreement over user behavior:
    • One side claims it’s “self-correcting” because users avoid sites that freeze them.
    • Others counter that typical users won’t link freeze ↔ site, will get caught in auto-restore loops, or be driven to call “tech support” scammers.

Responsibility: OS vs browser vs WebGPU

  • Some frame it primarily as a macOS bug: other OSes have GPU watchdogs that reset misbehaving workloads; macOS still lets GPU hangs take the whole system/WindowServer down.
  • Others see it as inherent to WebGPU/WebGL: the web should never be able to lock a machine, regardless of OS behavior.
  • Thread notes that Apple has closed similar WebGPU issues as “not security relevant.”

Broader views on WebGPU and web as app platform

  • Skeptical camp:
    • Worry about ever-expanding hardware attack surface in browsers (WebGPU, WebUSB, etc.).
    • Argue browsers were for documents, not as a full application/runtime layer, and we’re repeating mistakes of Java applets / Flash / ActiveX.
    • Some users disable WebGPU/WebGL entirely for security/privacy, accepting loss of rich apps.
  • Supportive/accepting camp:
    • Notes that native app distribution on desktops is insecure and fragmented; browsers provide a de facto cross-platform sandbox with a permission model.
    • Point out that many modern apps (Figma, Canva, Maps-like tools) depend on WebGL/WebGPU; turning them off is a big regression.
    • Some argue WebGPU doesn’t expose meaningfully more fingerprinting surface than WebGL already did.

GPU architecture & technical notes

  • Explanation that GPUs often lack fine-grained, OS-level preemption:
    • Large, expensive state; shared registers and memory make interrupting long-running shaders hard.
    • Many designs rely on cooperative yielding or coarse-grained boundaries, so a tight loop can monopolize the device.
  • Discussion of shader loop limits: historically, finite loops were enforced/unrolled; with general control flow, timeout-based protection is used instead.
  • WebGPU implementations sometimes inject huge down-counters to “guarantee” loop termination, but the counter is so large that the system can still hang long before the loop ends.
  • Observations that a simple compute shader loop can crash just the tab, while pairing it with waiting render passes is what pushes WindowServer over the edge; moving the canvas offscreen changes behavior, suggesting complex interactions in the compositing path.

Mitigations and workarounds discussed

  • Disable WebGPU (and optionally WebGL) globally or per-browser; several Firefox users mention doing this already.
  • Use browsers that:
    • Prompt before restoring crashed sessions, or
    • Allow starting without auto-loading all restored tabs.
  • If stuck in an auto-restore loop: quickly quit the browser as soon as its icon appears, or temporarily disconnect from the network; effectiveness of network disconnect is debated, especially with service workers.
  • Suggestion that extensions could stub out WebGPU APIs to no-ops on untrusted sites.
  • Some rely on hardened browsers/OSes (e.g., GrapheneOS Vanadium) which appear to recover more gracefully.

Historical parallels and anecdotes

  • Numerous references to earlier “fun” or malicious web tricks:
    • Infinite alert() loops, popup storms, and shock sites that blared audio and spammed windows.
    • Old Unicode or Wi-Fi SSID bugs that could crash iOS devices.
    • Browser pages that stressed memory/DevTools via infinite logging or heavy 3D scenes.
  • Some see the current bug as part of this long-standing class of browser-driven DoS, noting similar GPU hangs existed with WebGL and OpenCL years ago.