Over a Thousand Malicious npm Packets Spread RAT and Steal Data

A large-scale campaign turned the npm registry into a malware distribution treadmill for Windows, macOS, and Linux. The case began to draw attention on August 5, 2026, when researchers identified hundreds of components linked to the same loader. The initial count of almost 800 packages grew and reached1,033 confirmed components, according to the most recent update of the investigation.

The number is frightening, but the most important aspect is in the activation mode. Part of the packages did not depend on the well-known scriptspreinstallorpostinstall. The malicious code could start working when the developer followed the README lead and imported the library withrequire(). In practice, a seemingly common dependency gained access to the same environment as the project, including files, variables, and credentials available in that process.

This changes the security question. Don't just check if a package runs something during installation. You also need to knowWhat it does when it enters the code.

How the campaign was discovered

On August 5, Sonatype began to accompany the group under the nameFlooding Dropper. The next day, OpenSourceMalware published an analysis of the same operation, which its researchers callWEL1DROPPER. At that time, more than 700 packages would have been published in about 48 hours.

The scale increased rapidly. Sonatype related 846 components to the campaign, while Socket counted 865 artifacts, corresponding to 789 unique packages. On August 11, an update cited by The Hacker News brought the confirmed total to 1,033.

These numbers are not necessarily contradictory. Each company may count unique versions, artifacts, or packages differently, and the removal of malicious publications happens at the same time as new samples are discovered. What remains clear is that this was not an isolated package, but an automated operation distributed among several disposable accounts.

The scam started with the name and the README

The names mixed technical terms, commercial terms, and recurring words in combinations that seemed plausible at first glance. Researchers describe part of this pattern asAI slopsquatting, a variation of typosquatting in which strange names or names suggested by AI tools can be registered before the developer realizes that the library never really existed.

The README completed the trap. Instead of presenting a clearly suspicious function, it taught how to import the module like any SDK. The call loaded a helper file and started the infection chain immediately.

So disabling installation scripts remains a good layer of protection, butI wouldn't block this attack alone. The package could be quiet during thenpm installand take action during a test, a local boot, a build, or the server run.

What happened after importation

Once loaded, the first stage identified the operating system and processor architecture. It then attempted to download an executable compatible with Windows, macOS, or Linux from different HTTPS addresses.

If the direct connection failed, there was a second route: DNS queries of the TXT type. Encoded fragments of the file were retrieved, gathered, and written to a temporary folder. The process then started in the background, separate from the Node.js that had done the import.

This separation is important. Close the terminal, stop thenpm installor terminating the application does not guarantee that the downloaded binary has stopped. It can remain active, establish persistence, and seek new stages.

Public reviews describe different behaviors by platform:

on Windows, the malware seeks to make inspection difficult, scans analysis environments, and attempts to maintain persistence by logging and scheduled task;
on macOS, there are checks against debugging and use of LaunchAgent for persistence;
on Linux, researchers observed a packaged executable that delivers a deployment of the Sliver framework.

The possible outcome matchesRemote Access, execution of new payloads, and information theft. This puts at risk npm and GitHub tokens, cloud service keys, CI/CD secrets, and other data that is often available on development machines.

Why the number of packages matters

The campaign diluted the publications in several accounts, many of them responsible for a few packages. The code also received minor changes to function names and variables, although it maintained the same behavior.

This strategy increases the work of moderation. Taking down an account or blocking an exact signature does not end the operation. When hundreds of variations appear almost at the same time, lists of well-known names age quickly.

The case also exposes a growing risk of AI-assisted development. A model might suggest a convincing name that doesn't match a real library. If someone registers that name in advance, a made-up recommendation goes from producing just an error to pointing to hostile code.

This does not mean that every AI suggestion is dangerous. It means thatThe recommendation is not a substitute for checking the package, its author, and its origin.

What to do if the package has arrived at the project

Remove the dependency frompackage.jsonis not a sufficient response if it has been imported or executed. Sonatype's guidance is to treat the affected equipment as compromised.

A prudent response follows this order:

isolate the station, CI runner, or suspicious server from the network;
Check out lockfiles, caches, container images, and internal mirrors with the updated list of indicators provided by the researchers;
look for Node.js-derived processes, runnable in temporary directories, persistence, and unusual DNS queries;
Rebuild the environment from a trusted foundation when there is confirmation or strong suspicion of execution;
only after wiping, revoke sessions and exchange tokens from npm, GitHub, cloud, CI/CD, SSH keys, and other exposed secrets;
Review logs to find out if compromised credentials were used on another machine or service.

The exchange of credentials should happen from a clean device. Doing this before removing the malware may simply hand over the new secrets to the attacker.

How to reduce risk before the next installation

No single tool solves an attack on the software chain, but some practices reduce the surface quite a bit:

Confirm the spelling, maintainer, repository, and history of the package before adding it;
be wary of newly published libraries with strange names or documentation that doesn't match the code;
add new dependencies by code review, rather than installing directly at the suggestion of an AI;
Preserve the lockfile and usenpm ciin automations to avoid unexpected changes to the already approved tree;
keep CI runners ephemeral and with as few secrets and permissions as possible;
Monitor child processes, network accesses, and DNS queries initiated by build tools;
Verify signatures and attestations of provenance withnpm audit signatureswhen available;
Usenpm auditfor known vulnerabilities, without treating it as a full-fledged newly published malware detector.

Provenance helps confirm where and how a release was generated. It is valuable evidence, but it does not prove by itself that the behavior of the package is safe. The code, permissions, and actual need for the dependency still need to be reviewed.

What this case teaches

The WEL1DROPPER shows that trust in a dependency starts before installation and continues during execution. Script controls, blocklists, and scanners are important, but they lose strength when the trap uses new names, too many accounts, and code that only awakens at firstrequire().

For small teams, the most effective measure may also be the simplest:Add fewer dependencies and understand each new library before incorporating it. For companies, the same idea needs to become a process, with approval, observability, disposable environments, and a response prepared for credential compromise.

The npm registry removes malicious packages when they are identified, but the scale of this campaign leaves an uncomfortable lesson. Open source remains essential to modern development, but importing a library is granting execution within your project. This decision deserves the same attention given to any other software installed on the machine.

Sources consulted

Counting completed on August 23, 2026. Totals may change as new samples are identified or removed from the record.