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

A campaign of 148 npm packages disguised as student web proxies turned visitors’ browsers into a distributed denial-of-service (DDoS) botnet for roughly two weeks in May 2026, according to new research from JFrog. The packages, shipped under names like charlie-kirk, ilovefemboys, and miguelphonk, each carried a proxy app branded “Lucide” and dressed as a tutoring landing page called Riverbend Tutoring or Northstar Tutoring.

On the surface, the proxy worked, letting students slip past content filters to reach games and blocked sites. Underneath, it loaded a remote code loader whose payload the operators could swap at will, plus a WebSocket flood generator built to speak the Wisp proxy protocol. Anyone who opened a page joined the swarm without knowing it.

JFrog deobfuscated the app’s entry bundle, a 5.4 MB single line of JavaScript that unpacked into more than 20,600 lines of readable code, and recovered archived payloads from the Wayback Machine to reconstruct the campaign’s timeline. Two modules sat underneath the adware: G2, a remote script loader that fetches JavaScript from a GitHub repository through the jsDelivr CDN without Subresource Integrity checks, and I2, which fetches a plain text file (websocket.txt) holding a target WebSocket URL and a socket count capped between 1 and 1,024, then opens that many connections in a staggered loop.

The archived config aimed each browser at 30 connections to a Wisp endpoint on lunaron[.]top, itself a live proxy busy injecting malvertising. Once connected, each browser sets its socket to binary mode and, every 100 milliseconds, sends a valid Wisp CONNECT frame followed by a CLOSE frame, both pointed at localhost:1. That makes it a control-plane attack rather than a volumetric one. A single browser running the full 1,024 sockets can push a Wisp server to allocate and tear down about 10,240 connections a second while writing more than 20,000 log lines in the same stretch.

JFrog notes that Mercury Workshop’s wisp-server-node opens a fresh socket for every CONNECT frame without checking whether the destination is a loopback or private address, and logs each attempt. That exhausts file descriptors, floods log storage, and drops the proxy. wisp-server-node is already deprecated; its maintainers are pointing users elsewhere over exactly this class of security and stability problem.

The campaign turned a student proxy tool into a weapon against the servers that other student proxies depend on, and aimed a separate flood at a school on the side. The infrastructure is clustered tightly and not built to hide. JFrog traced the builds to a GitHub organization named lucideproxy whose accounts were registered seconds apart, tied to a commit email at geeked[.]wtf and a Discord handle. Ninety of the 93 deployment hostnames it found resolved to one IP address, 92.38.177[.]17, hosted by G-Core Labs.

JFrog’s commit history lays out the arc. The project started as plain adware in March, added the remote loader and the Wisp generator in a two-day burst in mid-May, ran the live flood against the nursing school at the end of the month, then stripped the malicious modules back out on May 31 as reporting started. A second wave on July 8, under a new account, brought the total to 148 packages and shipped the cleaned-up, adware-only build. The app is still obfuscated, still loads third-party scripts from attacker domains, and the loader still points at a mutable branch. The DDoS capability is not gone, only switched off.

Many of the campaign’s packages have since been pulled from npm and replaced with the registry’s standard 0.0.1-security placeholder. A spot check by The Hacker News across the package families on July 14, 2026, found most gone but charlie-kirk still serving the two versions JFrog flagged as malicious, 2.0.0 and 3.0.1.

Because the threat ships as a client-side web app rather than an install-time implant, JFrog’s remediation follows the delivery method. Administrators on school and corporate networks, where these proxies pull the most traffic, should block the campaign’s domains at the DNS level. The monetization and script hosts the current build still reaches, among them woofbeginner[.]com and c.vipersfutbol[.]com, are the ones to block first. Anyone who has loaded one of the proxy sites should clear the browser cache and local storage and unregister any service worker left behind by a tutoring or proxy domain. Teams whose build environments fetched the named packages should pull them from manifests and lockfiles and rebuild clean.