How to Detect Malicious npm Packages and Slopsquatting

To detect malicious npm packages, you check every dependency your project adds, direct and transitive, for the signals of a poisoned package: install scripts that run code, recently published or low-download packages impersonating popular ones, names that typosquat or slopsquat real libraries, and code that reaches out to the network or the filesystem at install time. The safest point to catch them is in the pull request that adds the dependency, before npm install ever runs on a developer machine or in CI. A malicious package is different from a vulnerable one: a vulnerable package has an accidental flaw, while a malicious package was published specifically to steal secrets or run attacker code.

Understanding how to detect malicious npm packages matters because the registry is a primary supply-chain target, and AI coding assistants have made the problem worse. When an assistant hallucinates a plausible-sounding package name, attackers register that exact name and wait, a tactic called slopsquatting, so code that looks fine can install a hostile package on first run.

What are the signs of a malicious npm package?

The tells are consistent across incidents. Watch for a package published very recently or with almost no download history but a popular-sounding name, an install or postinstall script that executes code during npm install, obfuscated code, network calls or environment-variable reads at install time, and a name one character or one typo away from a widely used library. Any single signal warrants a closer look; several together are a strong indication.

What is slopsquatting, and how is it different from typosquatting?

Typosquatting registers packages named after common typos of popular libraries, hoping a developer mistypes. Slopsquatting is the AI-era variant: attackers register package names that large language models tend to hallucinate when generating code, so a developer who copies an AI suggestion installs the attacker's package without ever making a typo. Both exploit trust in the name rather than a flaw in the code, which is why name-level and behavior-level checks both matter.

How do you catch malicious packages before they install?

Review dependency changes in the pull request, not after they are merged and installed. That means flagging newly added or updated packages, checking their reputation and publish history, inspecting for install scripts and suspicious behavior, and blocking the merge when a package looks hostile. ARGUS reviews every pull request for exactly this, combining vulnerability scanning of dependencies with malicious-package detection, and opens a fix as a pull request, so a poisoned or slopsquatted package is caught at the moment it is proposed rather than after it has run in your pipeline.

Frequently asked questions

Is a malicious package the same as a vulnerable one? No. A vulnerable package has an accidental flaw; a malicious package was created to attack you. Both need catching, but malicious packages often act at install time, so speed matters more.

Can lockfiles protect me? Lockfiles pin versions and help reproducibility, but they do not tell you a pinned package is malicious. You still need reputation and behavior checks on what you add.

How does AI-generated code increase this risk? Assistants sometimes invent package names, and attackers pre-register those names (slopsquatting), so blindly installing AI-suggested dependencies can pull in hostile code.

Our read

The npm supply chain is a trust system, and attackers attack the trust, not the code, by impersonating names developers and now AI assistants already believe in. The defensible response is to verify every dependency at the moment it is added, weighting behavior like install-time scripts and network access over reputation alone, and to do it in the pull request where a bad package can still be rejected. As slopsquatting grows alongside AI-assisted coding, catching the dependency before install, rather than cleaning up after, is what keeps one hallucinated package name from becoming a breach.

Supply-chain risk framing per CISA and the OWASP CI/CD Top 10. Sources linked above.

Related: SBOM for startups and what is a software supply chain attack?.