In May 2026, a sophisticated campaign deployed 148 npm packages disguised as student web proxies, successfully transforming the browsers of unsuspecting users into a distributed denial-of-service (DDoS) botnet. This incident highlights a dangerous evolution in supply chain attacks: the shift from compromising the build pipeline to weaponizing client-side execution.
1. The "Innocent" Registry Abuse
Traditional Software Composition Analysis (SCA) and Static Application Security Testing (SAST) tools are designed to catch malicious code at install time. This campaign completely bypassed those controls. The packages contained no lifecycle hooks or native build scripts. Instead, they acted merely as free hosting for a client-side web application, waiting silently until a user actively visited the proxy site to bypass school network filters.
2. The Mutable Branch Vulnerability
Once the proxy loaded in the browser, it executed a remote script loader that fetched JavaScript from a GitHub repository via a CDN. Critically, this request pointed to a mutable main branch without any Subresource Integrity (SRI) checks. This allowed the operators to silently swap the payload at will, executing code with the proxy site’s own origin privileges and full access to cookies and local storage.
3. Control-Plane Exhaustion Over Volumetric Flooding
While the botnet did launch crude HTTP floods, its more sophisticated module utilized the Wisp proxy protocol to open hundreds of WebSocket connections per browser. This was not a traditional volumetric attack; it was a control-plane attack designed to exhaust file descriptors and flood log storage on the target Wisp server, effectively crashing the infrastructure through legitimate-looking connection churn.
5. Strategic Defenses for a Client-Side Threat
Mitigating this class of attack requires moving beyond static code analysis. Organizations and educational institutions must implement strict Content Security Policies (CSP) to block unauthorized cross-origin script execution. Furthermore, enforcing Subresource Integrity (SRI) for all external scripts and deploying DNS-level blocking for known malicious monetization and script hosts are non negotiable baseline controls. For affected users, clearing browser cache, local storage, and unregistering lingering service workers is the only way to break the persistence mechanism.
As long as public package registries can be abused as free Content Delivery Networks for client-side applications, the attack surface will continue to expand far beyond the traditional build environment. Defenders must adapt their monitoring to detect anomalous runtime behavior, not just static code vulnerabilities.