WEL1DROPPER npm Campaign Hits Nearly 800 Packages

Security researchers say a single campaign has pushed nearly 800 malicious packages to the npm registry, each one carrying a downloader called WEL1DROPPER that pulls down a remote access trojan and an infostealer built for Windows, macOS and Linux. The packages were flagged over the past day and tie back to the "Flooding Dropper" activity that surfaced earlier in August. What changed is the scale and the delivery trick. Instead of relying on install scripts, the packages ship a README that tells developers to load them with require(), so the malicious code runs the moment the module is imported rather than at install time.

That detail matters because much of the defensive work over the past year has focused on lifecycle hooks. npm's v12 release started blocking install scripts by default to cut off preinstall and postinstall abuse. The WEL1DROPPER packages route around that control entirely by moving execution to require(), which no scanner can safely disable without breaking normal module loading.

What happened

According to a report published by The Hacker News and mirrored by SC Media, a cluster of close to 800 packages was uploaded to npm as part of a new cross-platform malware push. The packages carry randomly generated or typosquat-style names rather than impersonating one specific popular library. OpenSourceMalware researcher Paul McCarty described the names as "AI slop squatted, or randomly generated typo-squatting package names" and said all of them deliver the same RAT and infostealer payload.

The behavior is consistent across the set. Each package includes a README that instructs a developer to import it with require(), the built-in Node.js function used to load modules, local files and third-party packages. When the module loads, it runs a downloader that researchers are tracking as WEL1DROPPER. That downloader fingerprints the machine and fetches a matching binary, which is how the same package works against Windows, macOS and Linux hosts.

Palo Alto Networks Unit 42 documented a related but separate cluster of 10 npm packages in the same reporting window. Those packages export a getPlugin function that builds a download URL and pulls an obfuscated payload delivered as an immediately invoked function expression embedded in a JSON object. Unit 42 reported that the payload is a cryptocurrency stealer and remote access trojan that lets the operator run arbitrary commands on the infected host. Treat the two clusters as overlapping activity rather than a single confirmed operation, because the public reporting does not merge them.

Timeline

The exact first-seen dates for the 800 packages have not been published, so the timeline below reflects when the activity was reported, not necessarily when each package went live.

• Early August 2026: the Flooding Dropper campaign is first reported, delivering a cross-platform RAT through npm.
• August 11 to 12, 2026: The Hacker News and SC Media report that the campaign has grown to nearly 800 packages and name the WEL1DROPPER downloader, citing OpenSourceMalware and Unit 42.
• Same window: npm and third-party scanners continue flagging a broad flood of unrelated critical malware packages, a pattern that has held for weeks.

Who is affected

The primary target is any Node.js developer who installs and then imports one of these packages because a README, tutorial, or AI-generated instruction told them to. That is a narrower blast radius than a compromised popular dependency, but it is not small. Randomly named packages surface constantly in search results, in copied snippets, and in output from coding assistants, and the require()-first pattern means a developer only has to run the code once.

Cryptocurrency and web3 developers are a clear focus given that both the WEL1DROPPER payload and the Unit 42 getPlugin cluster carry crypto stealers alongside the RAT. Build servers and CI runners are also exposed, because a require() call inside a script or a test will execute the dropper with whatever credentials that environment holds. Since the payload runs on Windows, macOS and Linux, a mixed development team does not get a free pass on any platform.

This campaign is separate from the many other malicious packages flagged the same week. Examples that npm advisories and scanners published in the same window include dependencyfsdsfdsfg, base65-13x, and node-internal-svg-loader. We list them because they show how noisy the registry has been, not because they are confirmed parts of WEL1DROPPER.

How the WEL1DROPPER attack works

The chain has three stages. First, the developer installs the package and follows the README to require() it. Because there is no preinstall or postinstall script, the malicious behavior does not fire during npm install, which is exactly why install-script blocking does not stop it.

Second, the required module runs the WEL1DROPPER downloader. It reads the host operating system and processor architecture, then requests a compatible payload from one of three hosts running on Cloudflare Workers. Using Workers as the delivery point is deliberate. The traffic looks like ordinary HTTPS to a workers.dev endpoint, which blends into normal outbound activity and is harder to block wholesale than a random VPS.

Third, the payload executes. Researchers describe it as a combined remote access trojan and infostealer, with cryptocurrency theft functionality in both the WEL1DROPPER set and the related getPlugin packages. A RAT gives the operator hands-on-keyboard access to the machine. An infostealer scrapes tokens, environment variables and wallet material. On a developer workstation or a CI node, that combination is enough to pivot into private repositories, cloud accounts, and package publishing credentials, which is how single-machine infections turn into wider supply chain compromise.

How to check if you are affected

Because these packages use random names and run at require() time, dependency audits alone will not tell you the whole story. Start by listing everything installed and reviewing anything you do not recognize.

# Full installed tree with sources
npm ls --all

# Recently changed manifest and lockfile entries
git log -p -- package.json package-lock.json | head -n 200

Next, look for imports of packages that are not in your declared dependencies, and for any reference to Cloudflare Workers endpoints.

# Find require() calls that pull non-relative module names
grep -rEn "require\(['\"][^./]" ./src ./scripts 2>/dev/null

# Search installed code and your repo for workers.dev callbacks
grep -rEn "workers\.dev" node_modules ./src 2>/dev/null

On any host where a suspect package was imported, check for unexpected child processes and outbound connections. Endpoint detection logs, ~/.npm history, and shell history are all useful for reconstructing what ran. If you cannot rule out execution, assume it ran.

Remediation

Treat an infected developer machine or CI node as fully compromised, not just as a host with a bad dependency. The RAT plus infostealer combination means credentials in memory, on disk, and in environment variables should be considered stolen.

# Remove the suspect package and rebuild from a clean state
npm uninstall <suspicious-package>
rm -rf node_modules package-lock.json
npm cache clean --force
npm install

After cleaning the tree, rotate every secret the affected environment could reach. That includes npm tokens, GitHub and GitLab personal access tokens, cloud provider keys, and any signing or CI secrets. Rotate cryptocurrency wallet keys and move funds if a wallet was present on the machine, because the stealer targets exactly that material. Where possible, block egress to *.workers.dev from build infrastructure that has no reason to reach it, and enable install-script blocking with npm v12, understanding that it stops lifecycle-hook attacks but not require()-time execution.

For teams, add a rule that new dependencies must be pinned, reviewed, and never installed just because a README or an AI assistant suggested them. Randomly named packages with a single instruction to require() them are a strong signal to stop and verify the source.

FAQ

What is WEL1DROPPER?

WEL1DROPPER is the name researchers gave to a staged downloader embedded in nearly 800 malicious npm packages reported in August 2026. When a developer imports one of the packages with require(), the downloader identifies the operating system and CPU architecture and fetches a matching payload from a Cloudflare Workers host. The payload is a remote access trojan and infostealer that runs on Windows, macOS and Linux.

How do I know if I am affected by the WEL1DROPPER npm campaign?

Check whether anyone installed and then imported an unfamiliar, randomly named npm package, especially one whose README told you to load it with require(). Review your lockfile history and installed tree with npm ls --all, grep your code for require() calls that pull unknown module names, and look for outbound connections to workers.dev endpoints. If a suspect package was imported on a machine, treat that host as compromised and rotate its credentials.

Are these packages caught by npm's install-script blocking?

No. npm v12 blocks preinstall and postinstall scripts by default, which stops attacks that fire during npm install. WEL1DROPPER packages do not use those hooks. They run at require() time, so install-script blocking does not intercept them. You still want that control enabled, because it stops a large class of other supply chain attacks.

Is npm still safe to use?

npm remains usable, but the registry has seen a steady flood of malicious uploads through 2026, and this campaign is part of that pattern. The practical defense is unchanged: pin and review dependencies, do not install packages on the strength of a README or an AI suggestion, keep install-script blocking on, and treat any machine that ran unknown package code as a credential-exposure event.