2 min read

Free Hosting, Weaponized: How 148 npm Packages Turned Students' Browsers Into a Botnet- 260

Free Hosting, Weaponized: How 148 npm Packages Turned Students' Browsers Into a Botnet- 260

July 15, 2026

For roughly two weeks in May, a campaign hiding inside the npm package registry turned an ordinary tool for dodging school web filters into a weapon nobody who used it ever saw coming. The 148 packages at the center of the operation were never meant to be installed by developers at all — they existed purely as free hosting for a browser-based DDoS botnet, with students who loaded a disguised "tutoring" proxy page unknowingly supplying the attack traffic themselves.

The mechanism is what sets this campaign apart from the software-supply-chain attacks that have defined recent npm security incidents. Where the self-replicating Shai-Hulud worm and the phishing-driven compromise of the "qix" maintainer both fired at install time and targeted the developers building software, this operation skipped the build pipeline entirely and waited inside a browser tab. An initial disclosure in May read the packages as adware, cataloging popunder ads and monetization scripts bolted onto a proxy tool. Deeper analysis by JFrog, working from a deobfuscated 20,600-line JavaScript bundle and archived payloads pulled from the Wayback Machine, found two modules sitting beneath that adware layer: a remote script loader fetching unpinned, unverified code from a mutable GitHub branch with no integrity checks, and a second module capable of opening up to 1,024 WebSocket connections per browser against a target server using the Wisp tunneling protocol. An archived snapshot showed the loader had been used to fire a live HTTP flood against a nursing school's domain in Illinois, while the WebSocket module was configured to exhaust connection handling on a proxy server tied to the same browser-proxy ecosystem the malicious packages imitated.

What makes the episode most significant for defenders is less the specific payload than what it demonstrates about the boundaries of existing detection tooling. Dependency scanners and install-time sandboxes are built to catch code that executes when a package installs; this campaign's packages carried no lifecycle hooks and were never designed to be imported into a project at all, existing solely as free, disposable CDN hosting for a client-side web application. The operators, whose infrastructure and juvenile naming conventions point toward amateur rather than professional attribution, stripped the malicious modules out once reporting began in late May, then relaunched a cleaned-up, adware-only version in July under a new account — retaining, by design, the ability to re-arm the DDoS capability with a single commit to the same mutable code branch, no package update required. As public registries continue to double as free content-delivery infrastructure, the packages worth the most scrutiny may increasingly be the ones no build pipeline ever pulls.