A researcher writeup from September 10 describing a WebGPU busy-loop that hangs WindowServer, and in some cases panics M-series Macs, got a fresh round of amplification this month. Nothing in the underlying bug changed. Apple looked at it before this cycle of coverage started and declined to classify it as a security issue, which means no patch, no advisory, and no CVE tracking it. The trigger reportedly works across major browsers, not one rendering engine, because the path runs through the GPU compositor layer that WindowServer manages system-wide.
That distinction, security bug versus stability bug, is the whole story for anyone running headless or kiosk-mode browsers on Apple silicon as part of a pipeline. A crash that Apple will patch gets a timeline. A crash that Apple calls a stability issue gets nothing, and stays reproducible indefinitely. For data engineers running scraping fleets, headless rendering for PDF or screenshot generation, or QA automation on Mac minis in a rack, that distinction decides whether a known failure mode on M-series hardware is a scheduled fix or a permanent operating condition to route around.
Apple's decision not to treat the hang as a security issue is confirmed by its product behavior: no patch has shipped since the original writeup. What Apple has not disclosed is any internal severity assessment, timeline, or acknowledgment beyond the decision itself. The claim that the bug reaches across major browsers comes from the researcher's writeup and the secondary coverage repeating it; neither constitutes an Apple statement. Nobody has published telemetry on how often the hang triggers in production versus in a deliberate proof of concept, so the real-world frequency for a typical automated workload is unknown.
The mechanism matters more than the headline. WindowServer owns the compositing pipeline on macOS, so a busy-loop that starves it affects every window and every process waiting on a frame, not just the browser tab running the WebGPU call. That is why the failure can escalate from a hung tab to a full system panic on some M-series configurations: the browser is not the only thing blocked. For a job runner that expects a browser process to fail cleanly and respawn, a WindowServer hang can look instead like a dead instance that never returns an exit code, which is a different failure class for a watchdog to catch.
Operators moving data through headless browser steps should treat this as a known, unscheduled risk rather than a patchable bug with a due date. Pin browser versions where WebGPU can be disabled by flag, confirm whether the automation stack actually needs WebGPU at all, and check whether the fleet runs on M-series hardware specifically, since the reports are scoped to that silicon line, not Intel Macs. Build timeouts that assume the whole host, not just the browser process, can stop responding.
No patch is scheduled, Apple has made no further statement since declining to treat the hang as a security issue, and the bug remains live on M-series Macs running current browsers as of this month.