148 npm Packages Disguised as Student Proxies Reportedly Turned Browsers Into a DDoS Botnet

A large-scale JavaScript-ecosystem supply-chain compromise — this week's defender work is inventory, dependency review, and removal.

SAN FRANCISCO, CALIFORNIA — Researchers on July 14, 2026 disclosed 148 npm packages disguised as student-proxy tools that reportedly turned the browsers of people who ran them into a DDoS botnet, a large-scale compromise of the JavaScript package ecosystem. The packages were presented as utilities that would let students proxy web traffic; behind that framing, the reporting says, the code enlisted visiting browsers into a distributed denial-of-service botnet. For defenders, the immediate consequence is a dependency-inventory problem: determining whether any of the affected packages sit in an application's dependency tree and removing them if they do.

The campaign was reported by The Hacker News, under the headline "148 npm Packages Disguised as Student Proxies Turned Browsers Into a DDoS Botnet," which frames it as another case of the npm registry being used as low-cost distribution for code that behaves differently from what its listing advertises. At this stage it reads as a supply-chain-inventory exercise rather than a targeted intrusion: the response is dependency review, package removal, and egress monitoring rather than forensics on a breached perimeter.

What Researchers Disclosed

According to The Hacker News, researchers identified 148 npm packages disguised as student-proxy tools that reportedly turned the browsers of people who ran them into a DDoS botnet. The number — 148 — and the framing are the load-bearing facts: this is a volume campaign across the npm registry, not a single trojanized library, and the lure was consumer-grade, aimed at students looking to proxy their web traffic. For a defender the practical questions follow: are any of the affected packages in the codebase or a build's lockfile, and were they ever installed on developer or CI machines. The CyberSignal is deliberately not reconstructing how the packages assembled the botnet; that mechanism is the attacker's concern, not the defender's.

It is worth being precise about what the disclosure does and does not establish. It states that 148 npm packages were disguised as student proxies and reportedly turned browsers into a DDoS botnet. It does not, in the material available at the time of writing, pin down the exact list of the 148 packages, their cumulative download totals, a named threat actor, or whether npm has pulled the packages from the registry — gaps flagged in the open-questions section below rather than filled with inference.

A Continuing Strain on the JavaScript Supply Chain

This disclosure does not arrive in isolation; it is the latest entry in a run of JavaScript-ecosystem supply-chain incidents The CyberSignal has tracked this year. In the Jscrambler npm compromise, where attackers slipped a Rust-based infostealer into version 8.14 of trusted libraries, and in the Injective Labs incident, where a GitHub and npm compromise exposed a wallet key, the through-line is consistent: the registry is a trusted distribution channel, and code that reaches a developer's machine or a user's browser through it inherits that trust by default. The registry has been adjusting — when npm disabled install scripts by default for newly published packages, the change targeted exactly the class of abuse in which a package does something its listing never advertised — but a campaign of 148 packages is a reminder that ecosystem guardrails narrow the attack surface without closing it. The packages still have to be found, inventoried against real dependency trees, and removed, and that work falls to the teams that consume the registry.

Defender Posture for Organizations Depending on the Affected Packages

For any organization whose software or developers touch the npm ecosystem, the response is a well-worn checklist that requires no knowledge of how the botnet worked. Start with inventory: enumerate direct and transitive npm dependencies from lockfiles and a software bill of materials, then match a candidate list of the affected packages against what is actually installed — including on CI runners and developer laptops that may not appear in a production manifest. Where an affected package is found, remove it, rebuild cleanly, and rotate any credentials exposed on a machine where it ran. Because the reported effect is browser-based traffic, egress monitoring is the most relevant network-side control: unexpected outbound connections from browsers or build agents are what distinguish a dormant dependency from an active one. Pinning versions and scrutinizing packages with thin histories is the durable half of the response.

npm's Response and What to Watch

One consequential open item is the registry's own response: the disclosure does not establish whether npm has removed the 148 packages, and that changes the shape of the task. If they are pulled, new installations are blocked and the remaining work is cleaning up existing footholds; if they are still live, the exposure window stays open for whoever installs them next. The other thing to watch is whether this campaign connects to the broader pattern of volume-based package abuse seen this year — for example the contributor-account compromise that pushed 145 malicious packages through the Mastra project, or the way AI coding assistants have been leveraged as a delivery path in the hallusquatting research on botnet delivery through hallucinated package names. Whether the 148-package campaign shares infrastructure or tradecraft with any of those cases is not established, and that linkage, if it emerges, would move this from an isolated cleanup to a tracked cluster.

Scope and Impact

The scope is defined by three preserved facts: 148 packages, published to npm, disguised as student proxies, with a reported effect of turning browsers into a DDoS botnet. The disguise is instructive about reach. Student-proxy tools are consumer software with a wide, non-enterprise audience, so the population most directly exposed is individuals rather than hardened corporate environments — but the npm registry does not partition those worlds, and a package that reaches a shared library or internal tool can carry the exposure into an organization that never went looking for a student proxy. Beyond that, impact is not quantified: without download totals the number of affected installs is unknown, and without a package list teams cannot yet make a definitive match against their own dependencies.

Open Questions

Several material facts are unresolved at disclosure. The specific list of the 148 npm packages has not been established in the available material, which limits how precisely any organization can match the campaign against its own dependency tree. Total download counts are likewise not disclosed, leaving the campaign's real-world reach unquantified. No threat actor has been named.

It is also not confirmed whether npm has removed the packages — the single fact that most changes the defender's task from prevention to cleanup. The reporting at this stage rests principally on the account published by The Hacker News; that single-source-at-disclosure posture is normal for a freshly reported campaign and is not a reason to doubt the core facts, but the package list, the download figures, the attribution, and the registry's response may all be refined as more researchers and the registry weigh in. What is firm enough to act on is the shape of the incident — 148 npm packages, disguised as student proxies, reportedly turned browsers into a DDoS botnet — which justifies the defensive work without waiting for every particular.

The CyberSignal Analysis

The reported facts above come from the disclosure as carried by The Hacker News; what follows is The CyberSignal's editorial reading of what defenders should take from them. None of the judgments below are new reported facts.

Signal 01 — Treat It as an Inventory Problem, Not an Exploit to Study

The instinct with a botnet story is to want the mechanism — how the packages recruited browsers, how the traffic was shaped. For a defender that is a distraction. Nothing about reconstructing the botnet's internals changes the task in front of a team that consumes npm: find out whether any of the 148 packages are in its dependency tree and remove them if so. The right frame is asset inventory, not malware analysis, and the teams that respond fastest are the ones already keeping a current bill of materials. A consumer proxy campaign is unlikely to sit in a well-run production tree, but it can easily reach a developer laptop, a CI runner, or a lightly governed internal tool — and the value is in checking those places quickly.

Signal 02 — The Student-Proxy Lure Widens the Trust Surface

The choice to disguise the packages as student proxies is the detail we would dwell on. It aims the campaign at a young, non-enterprise audience motivated to route traffic around controls and unlikely to scrutinize what a package does — a group that overlaps, at the edges, with the people who later write code professionally on machines that touch corporate networks. The lure is chosen for reach, which is why an organization that never sought out a student proxy can still end up carrying one. Dependency review has to account for consumer-grade lures, not only typosquats and dependency-confusion tricks aimed at engineers.

Signal 03 — Registry Removal Is the Variable That Sets the Clock

The single fact we are watching hardest is whether npm removes the 148 packages, because it decides whether this is a closing window or an open one. If they come down, exposure is bounded to whoever already installed them and the work is cleanup; if they stay live, every new install extends the campaign. Our assessment is that the registry's response — more than the download count or the eventual attribution — is what will decide how large this incident ultimately reads. The practical takeaway is to treat registry status as a live signal, not a settled fact: inventory now, monitor egress, and revisit as the details firm up.

Sources