On March 31, 2026, the axios npm package was compromised. A maintainer account was hijacked, and two malicious versions (1.14.1 and 0.30.4) were published with a hidden dependency that deployed a cross-platform remote access trojan. The versions were live for about three hours before removal.
Axios has over 100 million weekly downloads. The blast radius was enormous.
If you maintain an MCP server, this matters to you directly.
What happened
The attacker gained publishing access to the official axios package on npm. They didn't modify any axios source files. Instead, they added a new dependency, plain-crypto-js@4.2.1, to the package.json. That package had a postinstall script that downloaded and executed platform-specific malware: a RAT on macOS, a PowerShell backdoor on Windows, a Python RAT on Linux.
The attack was sophisticated. The malicious dependency had a "clean" version (4.2.0) published 18 hours earlier to establish a brief history on the registry. The dropper used double-obfuscated code and self-deleted after execution.
Full technical details are in Snyk's write-up.
Why MCP server maintainers should care
MCP servers are npm packages. They have dependencies. Those dependencies have dependencies. If your MCP server depends on axios (or on a package that depends on axios), and you or your CI ran npm install without a lockfile during that three-hour window, you may have pulled the compromised version.
This is not a hypothetical scenario. We scanned 20 MCP server packages the week before the incident. Two of them, exa-mcp-server and tavily-mcp, depend on axios directly. Both use semver ranges (^1.13.6 and ^1.6.7 respectively) that would have resolved to the compromised 1.14.1 during the window.
The MCP ecosystem is growing fast. The official MCP site describes over 1,000 servers and 70+ compatible clients. Most of these are npm packages with conventional dependency trees. None of them are immune to supply chain attacks on popular packages.
What you should do now
Check your lockfile. If your package-lock.json or yarn.lock was committed before March 31 00:21 UTC and you did not run npm install during the window, you were not affected. Lockfiles are the first line of defence.
Search for the malicious dependency. Run npm ls plain-crypto-js in your project. If it appears, you were affected.
Pin your dependencies. Semver ranges like ^1.13.6 are convenient but dangerous. They resolve to the latest matching version at install time. During a supply chain attack, "latest" means "compromised."
Audit install scripts. The axios attack used a postinstall hook to execute the payload. You can run npm install --ignore-scripts in CI to prevent lifecycle scripts from executing, though this breaks packages that legitimately need postinstall steps.
Use lockfile enforcement in CI. Run npm ci instead of npm install. It installs exactly what the lockfile specifies, ignoring the registry's current latest.
What this looks like structurally
This attack worked because of three things:
Implicit trust in established packages. Axios has been around for years. Nobody expects it to suddenly contain malware. But the package is only as secure as the maintainer accounts with publishing access.
Transitive dependency blindness. Most developers don't audit their dependencies' dependencies. The malicious code was in
plain-crypto-js, a package most axios users had never heard of.Postinstall scripts as an attack vector. npm runs lifecycle scripts by default. A single
postinstallentry in a new dependency is enough to execute arbitrary code on every machine that installs it.
For MCP servers specifically, there is a fourth factor: MCP servers often need API tokens, file system access, and network permissions to function. A compromised dependency running inside an MCP server process has access to whatever the server has access to. That includes API keys, database connections, and the tools the server exposes to AI agents.
How we think about this
At AgentScore, we scan MCP packages for security issues. Our scanner checks for postinstall hooks with network calls, suspicious URLs, prompt injection patterns in metadata, and source code patterns like command injection and hardcoded secrets. We also run continuous monitoring on MCP packages and their direct dependencies, with alerts when versions change or risk levels shift.
Our scanner would have flagged plain-crypto-js@4.2.1 for its postinstall script. The question is whether you would have scanned it before installing it.
That is the real gap in the ecosystem right now. Not detection capability, but routine. Most MCP server maintainers do not regularly audit their dependency chains. Most do not have monitoring that would catch a new malicious transitive dependency between releases.
If you want to check your MCP server's dependency chain, you can scan it for free at agentscores.xyz. If you want ongoing monitoring, get in touch.
The broader picture
The same week as the axios compromise, Anthropic accidentally published Claude Code's source to npm via a packaging error. Different failure mode (accidental exposure, not malicious compromise) but the same underlying lesson: npm is critical infrastructure for the AI ecosystem, and packaging hygiene is not optional.
The MCP ecosystem is built on npm. As it grows, it inherits all of npm's supply chain risks. The question is not whether another package will be compromised, but when, and whether you will know about it before it reaches your production environment.
AgentScore scans MCP packages for security issues and monitors dependencies for changes. Free scanner, no signup required.
Top comments (0)