npm Slopsquatting Attack: 1,000+ Malicious Packages

A large-scale supply-chain campaign is flooding the npm registry with malicious packages that lean on a new twist: names that AI coding assistants are prone to inventing. Tracked as WEL1DROPPER, the operation published more than 700 packages in roughly 48 hours and has since grown past 1,000, according to OpenSourceMalware researcher Paul McCarty, who documented the campaign. Every package delivers the same thing — a cross-platform remote-access trojan (RAT) and infostealer — and the technique used to lure developers into installing them is what makes this one worth a close look.

What “slopsquatting” means

Traditional typosquatting registers packages whose names are one keystroke away from a popular library — expres for express, say — and waits for fat-fingered installs. Slopsquatting is the AI-era mutation of that idea. Instead of mimicking real names, attackers register plausible-sounding package names that large language models tend to hallucinate when a developer asks a coding assistant how to accomplish some task.

The connection runs straight through a well-documented failure mode of generative models. As covered in our explainer on LLM hallucinations, models routinely fabricate confident-sounding but nonexistent references — including import statements and package names that were never published. When enough developers paste a suggested npm install command without checking, a name that started as a model’s invention becomes a real download. WEL1DROPPER’s operators appear to have pre-registered a broad spread of such AI-hallucinated names — examples surfaced by researchers include entries like checkout-mobile-bnpl — betting that assistants would eventually recommend them.

No install script required

Most npm supply-chain attacks abuse lifecycle hooks — the preinstall and postinstall scripts that run automatically when a package is added. Defenders have learned to watch those hooks, and package managers increasingly let teams disable them. WEL1DROPPER sidesteps the whole category.

The malicious packages ship no install script at all. Instead, each one includes a README that instructs the developer to load the module with a plain require() call — for instance, require("checkout-mobile-bnpl"). That single import is the trigger. It executes a bundled _helpers.js file, which runs automatically the moment the module is imported. Because nothing fires at install time, a scan that only inspects lifecycle scripts sees a clean package. The malicious behavior lives in ordinary application code that the victim is socially engineered into running.

The payload chain

_helpers.js is a downloader, not the final malware. When executed, it fingerprints the host — identifying the operating system and processor architecture — and fetches a matching second-stage payload from one of three Cloudflare Workers hosts. Delivery also involves DNS TXT-record based retrieval, a channel that blends into normal network traffic and is harder to block than a hardcoded download URL.

The second stage is where the damage happens, and it is fully cross-platform, targeting Windows, macOS, and Linux:

• On Windows, the malware tampers with ETW (Event Tracing for Windows) and AMSI (Antimalware Scan Interface) to blind local defenses, then establishes persistence.
• On macOS, it installs a LaunchAgent for persistence.
• On Linux, it deploys Sliver, an open-source command-and-control framework popular with both red teams and real intruders.

From there the payload can perform host discovery, credential theft, persistence, and command-and-control — none of which is visible in the published npm package itself. A defender inspecting the registry artifact sees a small downloader; the RAT and infostealer only materialize after the second-stage fetch on a live machine.

Attribution and links to earlier campaigns

McCarty attributes WEL1DROPPER to a Russian threat actor with moderate confidence. The evidence he cites is circumstantial but consistent: a .ru command-and-control domain, and XOR-obfuscated strings buried in the code that reference Russian financial institutions such as tcsbank.ru and cloudpayments.ru — the kind of hardcoded targets that hint at where the operators expect stolen credentials to pay off.

The campaign also does not appear to be a first attempt. Researchers link WEL1DROPPER to an earlier operation called Moika, which pushed 250-plus npm packages between April and May 2026, based on shared tradecraft: “oob”-named infrastructure, fake telemetry used as camouflage, and similar kill-switch mechanisms that let the operators disable the malware remotely. The reuse suggests a maturing playbook rather than a one-off.

Why the registry keeps getting hit

None of this happens in a vacuum. Public package registries are the connective tissue of modern development, and their open publishing model — anyone can push a package under almost any unclaimed name — is exactly what makes campaigns like this cheap to run. We have written before about why software supply-chain security is now a first-order concern: a single compromised dependency, pulled transitively into thousands of builds, can outrun any individual team’s controls.

Slopsquatting adds a genuinely new vector on top of the old ones. Where typosquatting depended on human error, slopsquatting depends on machine error at scale — and the machines making that error are increasingly wired directly into developers’ editors and terminals. As AI assistants suggest more install commands, the payoff for pre-registering hallucinated names rises with them.

How to protect a codebase

The defenses are unglamorous but effective:

• Verify every package name before installing. Do not paste an npm install line from a chat assistant or a README without confirming the package exists, has a real maintainer, a plausible download history, and a source repository.
• Treat require() in setup instructions as a red flag. Legitimate libraries do not need a README telling you to import them to “activate” anything.
• Pin and lock dependencies, and review lockfile changes in code review the way you review source changes.
• Maintain a software bill of materials so you can answer “do we ship this package?” in minutes, not days, when the next campaign is named.
• Prefer package managers and settings that disable install scripts by default, and understand the tradeoffs between the major npm clients when you configure that behavior.
• Restrict outbound traffic from build agents so a downloader cannot casually reach Cloudflare Workers or resolve attacker-controlled DNS TXT records.

What it means

WEL1DROPPER is a preview of a threat model that will only intensify. The immediate damage — credential theft and RAT deployment across three operating systems — is serious but familiar. The structural shift is the input the attackers are exploiting: not a developer’s typo, but a language model’s confident invention. That closes the loop between two trends we cover constantly on their own — the supply-chain fragility of open registries and the hallucination tendencies of generative AI — into a single, self-reinforcing attack.

Who wins and loses is clear enough. Attackers get a scalable, low-cost lure that improves as AI adoption grows; the more assistants hallucinate a name, the more valuable it is to squat. Developers and the registries lose, at least until tooling catches up — and the countermeasures that matter most are provenance and verification at the point of install, not signature-scanning after the fact.

Two things are worth watching next. First, whether npm and rival registries move to proactively reserve or flag AI-hallucinated names before attackers claim them — a hard problem, because the space of plausible-but-fake names is effectively infinite. Second, whether AI coding tools begin validating that a suggested package actually exists and is trustworthy before recommending an install. Until one of those lands, the safest assumption is the oldest one in security: do not run code you have not verified, no matter how helpfully it was suggested.