In this post I will, in the wake of last week’s Axios vulnerability, discuss some actions you can take to harden your supply chain. Let’s start with some background on the incident first.

Background

Last week, on March 31st 2026, a malicious dependency was introduced into the Axios package. If you’re not familiar with Axios, it’s an HTTP client that’s very popular within the Node ecosystem.

I won’t go into the details but the gist is that the Axios maintainer’s NPM credentials were stolen. These where then used to publish two vulnerable Axios package versions with post install hooks that downloaded remote access trojans.

The vulnerable Axios packages where live for around 3 hours before they were removed from the npm registry.

This is quite scary. Even if you don’t directly depend on Axios, it’s quite likely that some other tool that you use do. So you may have been affected just by initiating a new project, running an install that resolves a vulnerable versions, or even just executing an ad hoc npx command during this time window.

If you want to learn more about the attack, the following articles are well worth a read:

• Supply Chain Attack on Axios Pulls Malicious Dependency from npm
• Axios Maintainer Confirms Social Engineering Attack Behind npm Compromise
• The Hidden Blast Radius of the Axios Compromise

Actions

So, how can we protect ourselves? A good start is to block lifecycle hooks (i.e. postinstall scripts) of dependencies by default. Explicitly whitelist the packages that should be allowed to use these hooks instead.

I recommend using the package manager pnpm. Since v10, lifecycle hooks are disabled by default. For npm and yarn you actively have to opt out.

To go even further we can incorporate some ideas from Mitigating supply chain attacks | PNPM:

• Delay dependency updates
• Enforce trust policy

With PNPM you can define a minimumReleaseAge setting that will delay installation of new package versions. The idea is that (popular) vulnerable package versions tend to be taken down within a few hours.

Another option is to enforce trust-policy=no-downgrade. This essentially checks that the package was published from a trusted environment. In many cases malicious packages have been “side deployed”, i.e. the attacker sidesteps the CI and publishes the compromised package directly to the npm registry. The trust policy option would block these cases (if previous package versions have been published with provenance).

So with these two options enabled, a PNPM config might look something like this:

# Delay installs by 1 day — gives time for malware detection before a new
# release reaches your machine. Increase to 10080 (1 week) for more caution.
minimum-release-age=1440

# Prevent install if a package's trust level has decreased vs its previous release
trust-policy=no-downgrade

There are also software like Aikido safe-chain and Socket firewall that essentially act like a firewall for package installations. Both of these options will intercept package downloads and consult their respective malware databases before proceeding with the install.

I’ve just started using Aikido safe-chain, and will probably look into Socket as well. I will get back to you on that.