# 148 npm Packages Weaponized as Browser Botnets: How Student Proxies Became DDoS Tools
In May 2026, researchers uncovered a sophisticated supply chain attack that inverted traditional npm security threats: instead of targeting developers at installation time, threat actors hid malicious code inside 148 packages designed to execute in the browsers of unsuspecting students. The campaign transformed web browsers into a distributed denial-of-service botnet, flooding a nursing school with traffic while disguising the attack as a legitimate student proxy service. The discovery reveals a new vector in the evolution of npm ecosystem attacks and raises difficult questions about how open-source registries can be abused when traditional defense mechanisms don't apply.
## The Threat
A coordinated campaign deployed 148 npm packages between April and May 2026, each masquerading as a student web proxy tool designed to bypass school content filters. Packages shipped under innocuous names—charlie-kirk, ilovefemboys, miguelphonk—bundled a proxy application branded "Lucide" and wrapped in fake tutoring landing pages claiming to be "Riverbend Tutoring" or "Northstar Tutoring."
On the surface, the proxy worked as advertised. Students who installed or used these packages could successfully circumvent school web filters and access blocked gaming sites and entertainment platforms. Beneath this functional layer, however, lay two malicious modules that transformed visitor browsers into attack nodes without user knowledge or consent.
The campaign targeted cdn.caan.edu, the public-facing domain of a nursing school in Matteson, Illinois, flooding it with HTTP requests and WebSocket connections. The attack ran for approximately two weeks before being discovered and disrupted, and the infected packages remained available on npm's public registry for weeks, potentially exposing thousands of students and developers.
## Background and Context
The npm ecosystem has become an increasingly attractive target for supply chain attacks, but the May 2026 campaign represents a notable departure from established threat patterns. Previous high-impact npm incidents followed a predictable script: exploit developer systems at install time using lifecycle hooks or build scripts, harvest credentials, and republish packages with stolen tokens to propagate the malware further.
The Shai-Hulud worm in September 2025 infected over 500 packages by stealing developer credentials and using them to re-publish malicious code—a classic developer-targeting approach. Days before Shai-Hulud, a phishing attack compromised the maintainer account "qix" and injected wallet-draining code into chalk, debug, and 16 other libraries with billions of combined weekly downloads. Both attacks fired at build time and prioritized developer compromise.
This new campaign ignored developers entirely. The 148 packages contained no lifecycle hooks, no native build scripts, and were never intended to be imported into legitimate software projects. Instead, they functioned as static hosting for a malicious web application, relying on students to visit a website hosted at or promoted alongside these npm packages. The attack weaponized the registry's discoverability and free hosting as a trojan horse to place malware directly in end-user browsers.
Earlier in May, SafeDep researchers had cataloged 141 of these packages and classified the campaign as adware and registry abuse—identifying third-party monetization scripts, Google Analytics tracking, and popunder advertisements bolted onto a Scramjet proxy. The characterization held true for the visible layer. Security researchers at JFrog later deobfuscated the application and recovered archived payloads, revealing that malware was the primary purpose and adware was merely camouflage.
## Technical Details
The attack consisted of three layers: a functional student proxy that established credibility, overlay monetization scripts that provided plausible deniability, and two hidden modules—designated G2 and I2 by JFrog researchers—that performed the actual DDoS operations.
### The Delivery Mechanism
Each package delivered a 5.4 MB minified JavaScript bundle. Once deobfuscated, the code expanded into over 20,600 lines of readable source. The application presented students with a React-based interface for managing proxy connections and browsing blocked sites, creating a seamless user experience that masked the malicious functionality below.
The package distribution strategy was deliberate and low-cost. Threat actors registered dozens of accounts on npm, published packages under different names to avoid pattern detection, and bundled them with identical proxy functionality. The registry's permissive policies on static hosting and the relative ease of publishing multiple packages enabled rapid, inexpensive deployment at scale.
### The G2 Remote Code Loader Module
The first malicious component, G2, is a remote script loader that fetches and executes JavaScript with minimal safety constraints. The module retrieves code from a GitHub repository via the jsDelivr CDN, pointing to the mutable main branch rather than pinning to a specific commit. No Subresource Integrity (SRI) check verifies the fetched code's authenticity, and the script runs with the proxy site's origin privileges—granting full access to cookies, local storage, and same-origin endpoints.
The loader includes a no-referrer policy to prevent the request source from being logged, making it difficult to trace the attack's origin. By the time JFrog conducted analysis, the GitHub repository had been deleted and returned a 404 error. However, archived versions from May 30 preserved the original payload: a crude but effective HTTP flood generator.
The HTTP flood component builds one-million-character strings every 500 milliseconds and fires them as no-cors POST requests against cdn.caan.edu. The requests never wait for a response, allowing them to stack up. Each active visitor generated roughly 2 MB per second of outbound traffic, meaning a thousand concurrent proxy users would deliver approximately 2 GB per second against the target. The no-cors directive bypasses CORS preflight checks, and randomized query parameters defeat caching proxies, ensuring that every request reaches the target infrastructure.
### The I2 WebSocket Flood Module
The second module, I2, demonstrates greater sophistication. It fetches a configuration file (websocket.txt) containing a target WebSocket URL and a socket count parameter (capped between 1 and 1,024), then opens that many WebSocket connections in a staggered loop.
This approach is sharper than blind HTTP flooding for several reasons. WebSocket connections maintain persistent state, can be directed at Wisp proxy protocol endpoints, and represent a more targeted attack vector against proxying infrastructure. The staggered opening pattern distributes connection establishment across time, reducing the likelihood of triggering intrusion detection systems that flag sudden spikes in connection attempts.
The separation of configuration from payload execution allowed threat actors to adjust the attack parameters in near-real-time. By changing the contents of websocket.txt, attackers could increase or decrease the number of simultaneous connections, switch targets, or modify the proxy protocol version without redeploying packages or recreating the G2 malware.
### Execution Timeline
Both G2 and I2 modules fire before the React interface renders, ensuring that attack traffic begins generating the moment a user opens the proxy website. This timing is critical: the user sees a functional application and has no indication that their browser has joined an attack swarm. The malware runs invisibly in the background, consuming bandwidth and compute resources while the student remains focused on bypassing school filters.
## Implications
This campaign carries significant implications across multiple stakeholder groups:
For npm and open-source registries, the incident exposes a vulnerability in security models that rely on lifecycle hook detection and developer-time analysis. Packages designed for client-side delivery—web applications, proxies, embedded tools—can evade traditional static analysis and run arbitrary code after installation without developer involvement. The registry's function as free static hosting, while valuable for legitimate projects, can be exploited to distribute malware to end users.
For organizations hosting content on shared infrastructure, the targeting of cdn.caan.edu demonstrates that institutions without robust DDoS mitigation can be struck by botnets with minimal sophistication. A thousand concurrent proxies generating 2 GB per second of traffic can overwhelm smaller networks, taking services offline without requiring advanced exploitation techniques.
For students and casual users, the campaign illustrates the risk of using unvetted proxy tools from untrustworthy sources. Even if a proxy functions as advertised, it can silently enlist a user's device in attacks on third-party targets. There is no user-facing indication that their browser has been weaponized.
For cybersecurity, the incident marks a shift in npm threat modeling. Defenders have focused on protecting developer supply chains—monitoring for compromised accounts, suspicious build scripts, and credential harvesting. This campaign demonstrates that end-user-facing packages warrant comparable scrutiny, and that attack success does not require developer compromise.
The two-week operational window—during which 148 packages remained available and active—also highlights the detection and remediation lag in the npm ecosystem. Weeks of traffic data were likely captured, but discovery relied on external research teams, not registry-native anomaly detection.
## Recommendations
For enterprises and development teams:
For npm and open-source registries:
For schools and institutions:
## HackWire Analysis
This campaign represents a meaningful inflection point in npm supply chain threats. Previous attacks prioritized developer compromise—stealing credentials, spreading through build pipelines, and leveraging the trust developers place in their dependencies. The security industry built defenses around this model: lifecycle hook monitoring, code signing, credential scanning, and sandboxed CI/CD environments.
The May 2026 campaign inverts that calculus by accepting that end users, not developers, are the actual payload delivery mechanism. The threat actors made a strategic choice: rather than invest in developer credential harvesting or account compromise, they published 148 packages, accepted that most would be discovered and removed within weeks, and extracted maximum value from the subset that remained active. This is a numbers game where scale compensates for low sophistication.
The pattern mirrors a broader shift in the threat landscape. As enterprises harden developer workflows and prioritize SBOM (Software Bill of Materials) analysis, attackers are exploiting the asymmetry between developer-time security and runtime execution. A proxy application that functions perfectly and generates real value (bypassing school filters) has a much higher chance of surviving in a user's environment than obfuscated malware. The attack succeeds not because it's sophisticated, but because it's believable.
For defenders, the implication is uncomfortable: the most effective supply chain attacks may not be the ones that target developers at all. They're the ones that hide in plain sight, deliver real functionality, and run code with the privilege level of the end user. Npm's registry cannot function as both free web hosting and a trusted source of developer dependencies without accepting this risk.
The question now is whether registries can detect and respond to this attack class faster than threat actors can deploy new campaigns. At present, the answer appears to be no.
— HackWire Editorial
## Related Coverage