148 npm packages ran a browser-based DDoS botnet in May

The npm registry is a package host. It also serves the tarball contents over the public web, which means anything with a valid package.json becomes reachable at a stable URL and cached at Fastly’s edge — free hosting with a CDN, no signup beyond an email address. That is the observation the operator behind 148 npm packages caught by JFrog built on top of. For roughly two weeks in May, those packages were the storefront for a fake “student web proxy” — the kind of site kids use to reach a blocked domain from a school network — and the JavaScript that loaded when a student visited was quietly turning the visiting browser into one node of a distributed denial-of-service botnet.

The mechanic is worth being precise about, because it inverts the shape of the story a supply-chain incident usually takes. Nothing here targeted developers. Nothing here waited for a postinstall script to run on a build server. The published packages did not need to be installed to do their job; they only needed to be served. The registry was being used as content-delivery infrastructure for a booby-trapped web application, and the victims were the people who came to that web application looking for a free open proxy — mostly, per JFrog, students trying to bypass school content filters. Their browser fetched the JavaScript. The JavaScript included proxying behavior that made the visit look legitimate, and it also included a request loop pointed at a target of the operator’s choosing. Each visitor, for as long as the tab stayed open, added one more source IP to the aggregate load hitting that target.

Two things about that deserve to sit alongside each other. First: the class of attack — recruiting third-party browsers into an outbound HTTP-flood pool — is old. Search “in-browser DDoS” and the writeups go back more than a decade; it has happened on ad networks, on compromised WordPress themes, on typosquatted CDN URLs. The novelty here is not the payload. The novelty is where the payload was parked. Second: the npm registry does not, as of this writing, publicly document a takedown SLA for content-abuse-that-is-not-malicious-code. A package that installs a wallet stealer is easy to describe against npm’s acceptable-use policy. A package that installs cleanly, does nothing malicious on the developer’s machine, and only misbehaves when its tarball URL is loaded in a browser occupies a slightly different corner of the same policy space. The 148 packages sat live for approximately two weeks before the campaign was reported, per JFrog’s timeline — long enough to matter, short enough that it is not obviously a monitoring gap so much as a category the automated scanners were not tuned to catch.

For defenders, the mitigations do not involve npm ecosystem hygiene in the usual sense. If your organization runs an outbound proxy or web filter, the useful action is a log review of connections to registry.npmjs.org-hosted tarball URLs originating from user browsers rather than from build systems — those two populations look very different, and browser-originated tarball fetches are the anomaly. School networks are the more directly affected population; the Family Educational Rights and Privacy Act side of that is not our beat, but the network-side mitigation is: block outbound requests to arbitrary registry tarball URLs from the student LAN, or at minimum, alert on them.

This connects to a broader line running through the last month of registry coverage — rollup polyfill typosquats, Jscrambler’s compromised publish tokens, hallucinated package names getting registered — each different in its specifics, all instances of the same underlying observation. npm is one of the most reliable pieces of software-distribution infrastructure on the internet, and that reliability is a resource. It is being used, quietly, for jobs the registry was not designed to do.

The specific thing to check: whether any of the 148 packages (JFrog’s writeup lists them) appear in your organization’s outbound traffic in the May window. Not in your build logs. In your web-proxy logs.