A WebGPU busy-loop that can hang WindowServer, and in some cases panic M-series Macs, is spreading through browser tabs after a September 10 researcher writeup got picked up by secondary coverage this week. The bug itself is not new. What changed is visibility. Apple has already looked at this one and declined to classify it as a security issue, and no patch or mitigation has shipped as a result. That decision predates this week's attention cycle, so the renewed circulation does not reflect any new action from Apple. It reflects wider awareness of an existing, unresolved condition.
That distinction matters for anyone running fleets of Macs or supporting users who do. Apple's public position is that this does not meet its bar for a security fix, which means there is no CVE, no advisory, and no timeline to point to when a user or a monitoring system reports the symptom. Confirmed: the hang and panic behavior exists in major browsers on M-series hardware, per the researcher writeup now amplified across coverage. Confirmed: Apple reviewed it and declined to treat it as a security problem. Not disclosed: why Apple made that call, whether it considers the behavior a stability bug outside the security track, or whether any fix is planned under a different label.
The mechanism is straightforward enough to check for. A WebGPU workload that spins in a tight loop can starve WindowServer, the process macOS uses to composite and manage on-screen rendering, and a starved WindowServer can present as anything from a frozen cursor to a full panic depending on load and hardware. Because the trigger lives in browser-accessible WebGPU code, any tab, extension, or embedded web view capable of running that workload is a candidate, not just a specific site. That broadens the surface past whatever host the original researcher used to demonstrate it.
For on-call engineers, the operational risk is less about a new outage and more about misdiagnosis. A fleet of M-series Macs experiencing scattered WindowServer hangs or spontaneous panics now has a plausible non-hardware explanation that will not show up in a vendor advisory search. Check crash logs for WindowServer-related panics correlated with browser activity, check whether affected machines share browser versions or extensions with WebGPU access, and check whether existing MDM policy can restrict or flag WebGPU usage as a stopgap. None of that is confirmed as the fix. It is the closest thing to a workaround given what Apple has and has not said.
What stays unresolved is scope and duration. Apple has not stated which M-series chips are affected, which browser versions carry the vulnerable WebGPU implementation, or whether a future macOS release addresses the underlying resource starvation even without calling it a security patch. The researcher writeup and its amplification establish that the behavior is reproducible and public. They do not establish a remediation path. Until Apple issues something more specific than its original declination, the operating assumption for any fleet running M-series hardware should be that the bug is present and unaddressed. Apple shipped no product change as of September 12.