In March 2026, a malicious version of the axios npm package was briefly published to the registry before being caught and removed. The attack was short-lived but the mechanics were instructive — and the response from the community revealed some uncomfortable truths about how most teams think about dependency security.

What actually happened

The attack exploited a combination of a compromised maintainer account and a gap in the npm publish permissions model. The malicious version incremented the patch version (to avoid triggering version pinning alerts in most monitoring setups), and included a postinstall script that exfiltrated environment variables to an external endpoint.

The exfiltration target was a newly registered domain that was flagged by several threat intelligence feeds within hours. npm removed the package from the registry approximately 4 hours after publication.

The uncomfortable part

Most teams running npm install with a loose version constraint (e.g., ^1.7.2) would have installed the malicious version during that window. package-lock.json prevents this only if you never run npm install without a lockfile — but CI environments that run fresh installs are common.

The more uncomfortable fact: if you're using axios in a Node.js backend with access to database credentials, API keys, or tokens in your environment, those secrets would have been exfiltrated. Not as a theoretical risk. As a near-miss that almost happened in production.

What you should actually do

The pragmatic list, in rough priority order:

• Pin exact versions in package.json, not ranges. The convenience of semver ranges is not worth the attack surface.
• Commit your lockfile and verify it in CI. If your CI re-resolves dependencies, you're running a different install than your lock specifies.
• Run npm audit in CI and fail the build on high-severity findings. You probably already know this. Actually do it.
• Separate your secrets model from your environment model. Secrets in environment variables are convenient and insecure. Use a secrets manager.
• Enable npm's 2FA enforcement for all package maintainers, including automated publishing accounts.

The tools exist. The gap is almost always process, not tooling.