← Back to Blog

Supply Chain Attacks in Modern Software Development: The Axios Incident

Pentesting March 31, 2026 13 min read

Software development runs on trust. Trust that the package you are installing does what it says on the tin. That the maintainers are who they claim to be. That the npm registry has not been trojaned. Supply chain attacks strike directly at that foundation, and the recent Axios incident is a perfect illustration of why this is one of the most dangerous threats facing modern software development.

What Are Supply Chain Attacks?

A supply chain attack does not target your code directly. Instead, the attacker compromises the tools, libraries, or processes that your code depends on. The results are devastating precisely because the attack travels through legitimate channels: signed packages, trusted registries, widely-used libraries.

A modern Node.js application can have hundreds of transitive dependencies, each maintained by individuals or small teams, often without any formal security review. npm alone hosts over 2.5 million packages. Most developers install them with a single command and zero scrutiny. That blind trust is the attack surface.

Why supply chain attacks are so dangerous:

  • The attacker bypasses your application's security by striking before your code even runs
  • A legitimate package containing malicious code passes through the same review processes as the original - or none at all
  • One compromised package can hit millions of developers simultaneously
  • Detection is extremely difficult because the attack originates from a trusted source

Anatomy of the Axios Attack

In March 2026, the security community identified a critical supply chain compromise affecting Axios - one of the most widely used HTTP client libraries in the JavaScript ecosystem with over 83 million weekly downloads.

What happened:

A threat actor compromised a maintainer account with access to the Axios npm package. Using that access, they published two malicious versions: 1.14.1 and 0.30.4. These versions introduced a new dependency called plain-crypto-js - an innocuous-sounding package with a single purpose: executing a Remote Access Trojan (RAT) on the developer's machine.

The mechanism:

The attack leveraged npm's postinstall lifecycle hook - a script that runs automatically after a package is installed. The malicious postinstall script inside plain-crypto-js downloaded and executed a RAT payload, then attempted to erase its own tracks by removing the script artifacts. By the time most developers noticed something was wrong, the damage was already done.

This is a textbook supply chain attack:

  • Trusted vector: Axios is a legitimate, widely-audited library
  • Credential compromise: The attacker did not need to find a code vulnerability - just steal one set of maintainer credentials
  • Automatic execution: No user interaction was required; the RAT ran during a routine npm install
  • Anti-forensics: The malicious script self-deleted to complicate detection

The Hidden Risk of AI Coding Tools

Here is the part most security advisories miss: AI coding tools have made this significantly worse.

Tools like Claude Code, ChatGPT sandboxes, GitHub Copilot Workspace, and others routinely run npm install autonomously in the background. You describe a feature, the AI writes code, scaffolds a project, adds dependencies, and runs the installer without ever asking you. In an agentic workflow, the AI might install dozens of packages across multiple sessions before you review a single line of code.

If any of those packages contains a malicious postinstall script - as was the case with the Axios attack - the RAT executes silently on your development machine. Your machine. Your environment. Your SSH keys, API tokens, cloud credentials, .env files.

This is not theoretical. If your AI coding tool installed any npm package between when the malicious Axios versions went live and when they were taken down, you need to audit your environment right now.

Step-by-Step: How to Check if Your Machine Is Compromised

Step 1: Check for Malicious Axios Versions

Run the following command in any Node.js project directory on your machine: 

npm ls axios

You are looking for versions 1.14.1 or 0.30.4 in the output. If you see either of these, stop what you are doing and proceed to the remediation section below.

Also audit your lock files directly. Search for these version strings in package-lock.json, yarn.lock, or pnpm-lock.yaml: 

grep -r "axios" package-lock.json | grep "1\.14\.1\|0\.30\.4"

Or for yarn or pnpm:

grep -A 1 "axios" yarn.lock | grep "1\.14\.1\|0\.30\.4"

Step 2: Check for the Malicious Dependency

The malicious versions inject a package called plain-crypto-js. Check if it exists anywhere in your dependency tree: 

npm ls plain-crypto-js

If this package appears anywhere, even as a transitive dependency, treat your system as compromised.

You can also search globally across all your projects:

find ~/projects -name "package-lock.json" -exec grep -l "plain-crypto-js" {} \;

Step 3: Audit Your Lock Files Directly

Your lock files are the source of truth. Even if you have already run npm install since the incident, the version that was installed is recorded here. Search explicitly: 

grep "plain-crypto-js" package-lock.json
grep '"version": "1.14.1"' package-lock.json

If You Found the Malicious Versions: Assume Total Machine Compromise

If your checks above returned a hit on Axios 1.14.1 or 0.30.4, or if plain-crypto-js appears anywhere in your dependency tree, you must assume your machine is fully compromised. Do not dismiss this as a false positive. Do not assume "the script probably did not run." Treat this as a confirmed breach and act accordingly.

1. Rotate Every Secret Immediately

Before touching anything else, assume all credentials stored on or accessed from this machine have been exfiltrated:

  • SSH keys: Revoke and regenerate all SSH keys. Update them on GitHub, GitLab, Bitbucket, and any servers you access.
  • Cloud credentials: Rotate all AWS access keys, GCP service account keys, Azure credentials. Check your cloud provider's IAM for unauthorized access or resource creation.
  • API tokens: Revoke all API tokens - GitHub personal access tokens, npm tokens, CI/CD tokens, Stripe, Twilio, and anything else.
  • Environment variables: Every .env file that has ever been open on this machine should be treated as compromised. Rotate all values.
  • Browser sessions: Log out of all services and force session invalidation where possible.
  • Password manager: If your master password was typed on this machine, change it and review for unauthorized logins.

2. Nuke node_modules and Reinstall Safely

Remove the contaminated packages entirely:

rm -rf node_modules package-lock.json

Before reinstalling, pin Axios to a safe version in your package.json. Replace whatever version you have with: 

"axios": "1.14.0"

Or for the 0.x branch:

"axios": "0.30.3"

Then reinstall:

npm install

3. Pin Axios to a Safe Version

Use an exact version pin - remove the ^ or ~ prefix - to prevent automatic upgrades to future potentially malicious versions: 

npm install --save-exact axios@1.14.0

4. Disable postinstall Scripts Project-Wide

Create or edit .npmrc in your project root (or globally at ~/.npmrc) and add: 

ignore-scripts=true

This prevents npm from running lifecycle scripts - including postinstall, preinstall, and install - automatically on every package. Note that this may break some legitimate packages that rely on build scripts. Audit which packages need scripts enabled and whitelist them explicitly.

For Yarn:

yarn config set ignore-scripts true

For pnpm, add to .npmrc:

ignore-scripts=true

Broader Lessons: Hardening Your Supply Chain

The Axios incident is not an anomaly - it is a preview. Supply chain attacks are increasing in frequency and sophistication. SolarWinds in 2020, ua-parser-js in 2021, node-ipc in 2022 - the pattern is clear and accelerating.

What you can do today:

  • Audit your dependencies regularly with npm audit and tools like socket.dev or Snyk
  • Enable 2FA on your npm account - compromised maintainer credentials are the number one attack vector in this category
  • Use lockfiles and commit them to version control - they make version changes auditable and reviewable
  • Set ignore-scripts=true by default and only enable scripts for packages you have explicitly reviewed
  • Consider private registry mirrors (Verdaccio, Nexus) to snapshot known-good versions
  • Subscribe to security advisories - npm's security team and GitHub's Dependabot both publish timely alerts

The trust model of open-source package management is fundamentally broken when a single compromised npm account can push malicious code to 83 million weekly downloads. Until that changes at the ecosystem level, the responsibility falls on individual developers to audit what they are running.

If you want to talk through your project's dependency security posture or get a second pair of eyes on your CI/CD pipeline, reach out on LinkedIn or through the contact form.