TL;DR
In 2025, the OpenClaw campaign published roughly 900 malicious npm packages using typosquatting and dependency confusion. Payloads included credential stealers, reverse shells, and data exfiltration. This is especially dangerous for vibe coders because AI coding tools suggest packages by name, not by security audit. When Cursor or Claude says npm install some-package, it has no idea if that package is legitimate.
You have probably run npm install thousands of times without thinking about it. It is a reflex, not a decision. Type the package name, hit enter, move on.
That reflex is exactly what the OpenClaw attackers exploited.
What Happened
Over several months in 2025, a threat actor group published approximately 900 malicious packages to the npm registry. The campaign was methodical. Each package was designed to look like a legitimate, popular package, with names just slightly different from the real thing.
The packages were not empty shells. They contained functional code that appeared to do what the name suggested. But buried in postinstall scripts or obfuscated helper files, they also ran payloads that:
- Stole credentials from environment variables,
.envfiles, and cloud provider configs - Installed reverse shells giving attackers persistent access to developer machines
- Exfiltrated data including SSH keys, AWS credentials, and database connection strings
- Modified other packages in
node_modulesto maintain persistence even after the malicious package was removed
How the Attack Worked
OpenClaw used two primary techniques that are well-known but still devastatingly effective.
Typosquatting
The attackers registered package names that were slight misspellings of popular packages. Think expresss instead of express, or lodahs instead of lodash. A single character difference that is easy to miss, especially when you are typing fast or copying a suggestion from an AI tool.
Typosquatting works because developers trust their muscle memory. When an AI tool suggests a package name, you trust it even more, because you assume the AI knows what it is talking about.
Dependency Confusion
Some packages targeted internal company package names. npm's default resolution prefers public registry packages over private ones if the version number is higher. By publishing a public package with the same name as a private internal package but with a higher version number, the attacker's code gets installed instead.
If your company uses private npm packages without a scoped namespace (@company/package-name), you are vulnerable to dependency confusion attacks right now. Run npm config get registry to verify your registry configuration.
Why This Hits Vibe Coders Harder
Traditional developers have workflows that provide some friction. Code reviews. Dependency approval processes. Senior developers who recognize unfamiliar package names.
Vibe coders often do not have these guardrails.
AI Tools Suggest Packages by Name, Not by Reputation
When Cursor, Bolt, or Claude suggests npm install some-package, it is drawing on training data about package names. It has no real-time knowledge of whether that package is still maintained, whether the author is trustworthy, or whether the package was published yesterday by an attacker.
The AI cannot run npm audit. It cannot check download counts. It cannot verify the package author's identity. It just knows the name fits the context.
The Speed of Vibe Coding Removes Friction
When you are building fast, iterating with AI, and shipping in a weekend, every npm install feels like a step toward the finish line. Stopping to vet a package breaks your flow. So you do not stop.
That is the exact behavior supply chain attackers count on.
Treat every npm install suggested by an AI tool the same way you would treat a link in an email from a stranger. Verify before you click.
Postinstall Scripts Run Automatically
By default, npm runs lifecycle scripts (preinstall, install, postinstall) automatically when you install a package. A malicious postinstall script can execute arbitrary code on your machine the moment you run npm install. You do not even need to import the package in your code.
How to Protect Yourself
The good news: defending against supply chain attacks does not require exotic tools. It requires discipline and a few configuration changes.
1. Always Check Before You Install
Before running npm install anything-new:
- Search for it on npmjs.com. Check the download count, publish history, and linked GitHub repo.
- Look at the publisher. A package published by a new account with no other packages is suspicious.
- Compare the name carefully. If an AI suggested it, double-check the spelling against the official docs.
2. Use npm audit Regularly
npm audit
This checks your dependency tree against the npm advisory database. Run it after every install and as part of your CI pipeline.
3. Disable Automatic Script Execution
Add this to your .npmrc:
ignore-scripts=true
This prevents postinstall scripts from running automatically. You will need to manually run scripts for packages that require them (like node-gyp builds), but it eliminates the most dangerous attack vector.
4. Lock Your Dependencies
Always commit your package-lock.json. This ensures that:
- Everyone on your team installs the exact same versions
- A compromised new version of a dependency does not silently slip in
- You can diff changes to your dependency tree in code review
5. Use Scoped Packages for Internal Code
If your company publishes internal packages, always use a scoped namespace:
{
"name": "@yourcompany/internal-utils"
}
Scoped packages cannot be hijacked through dependency confusion.
6. Review What AI Installs
After an AI coding session, review your package.json diff:
git diff package.json
Look for packages you did not explicitly ask for. AI tools sometimes add dependencies you did not request, and those are the ones most likely to be wrong.
- Does it have more than 1,000 weekly downloads?
- Has it been published for more than 6 months?
- Does the publisher have other well-known packages?
- Is there a linked, active GitHub repository?
- Does the name match exactly what the official docs recommend?
If any answer is "no," investigate further before installing.
This Is Not Theoretical
Real developers got hit by OpenClaw. Credentials were stolen. Machines were compromised. Production databases were accessed through exfiltrated connection strings.
The npm registry removed the malicious packages after they were reported, but removal does not help the developers who already installed them. npm has no mechanism to remotely uninstall a package from your machine or notify you that something you installed was later flagged as malicious.
This means the responsibility is entirely on you. Nobody is watching your node_modules folder except you.
The Broader Problem
OpenClaw was not the first npm supply chain attack, and it will not be the last. The npm registry has over 2 million packages. Anyone can publish a package in minutes. There is no review process, no code signing requirement, and minimal identity verification for publishers.
AI coding tools are accelerating the problem. They make it faster to build, which means more packages get installed with less scrutiny. The attack surface grows with every npm install that goes unvetted.
The solution is not to stop using npm or to stop using AI tools. It is to add a verification step to your workflow. Five minutes of vetting can prevent weeks of incident response.
What was the OpenClaw campaign?
OpenClaw was a sustained supply chain attack in 2025 where threat actors published approximately 900 malicious npm packages. These packages used typosquatting and dependency confusion to trick developers into installing them. Payloads included credential stealers, reverse shells, and data exfiltration scripts.
Can AI coding tools install malicious packages?
Yes. AI coding tools suggest packages based on name patterns and training data, not security audits. If a malicious package has a name similar to a popular one, an AI tool might suggest it. The AI has no way to verify whether a package is legitimate or malicious at the time of suggestion.
How do I check if I installed a malicious npm package?
Run npm audit to check for known vulnerabilities. Review your package-lock.json for unfamiliar packages. Check download counts and publisher history on npmjs.com. Look for packages with very low download counts, recent publish dates, and no GitHub repository linked.
What should I do if I find a malicious package in my project?
Remove it immediately with npm uninstall. Rotate any credentials or API keys that were accessible to the package. Check your system for unauthorized SSH keys or new user accounts. Review outbound network connections. If the package had postinstall scripts, assume your environment is compromised and rotate all secrets.
OpenClaw proved that npm install is a trust decision. Find out what your AI-suggested dependencies are actually doing.