Axios Just Broke Our Trust, And That’s the Real Problem

Published on 3/31/2026

Your code might be safe, but your dependencies aren’t

NpmBashOpen Source

The Incident

If you use axios, open your lockfile right now.

Before you read anything else.

Today, the axios npm package was hit by a supply chain attack. Vercel's security team flagged two compromised versions:

axios@1.14.1
axios@0.30.4

These versions were silently sending data to an external server in the background. You would never know just by looking at your application code.

Why Supply Chain Attacks Are So Dangerous

You can write clean, well-reviewed code and still ship something malicious, not because of anything you did wrong, but because a package you trusted for years got compromised overnight.

Most developers never think about supply chain security until something like this happens. A single tampered dependency, nested three levels deep, can silently leak your users' data, API keys, and credentials.

This is why lockfiles matter.

How to Check if You Are Affected

Step 1 — Install ripgrep

ripgrep (rg) is a fast search tool required to run the scan.

macOS

brew install ripgrep

Linux (Ubuntu / Debian)

sudo apt install ripgrep

Windows (Chocolatey)

choco install ripgrep

Step 2 - Scan your lockfiles

Run the following command against your project directory:

rg -n --hidden \
  --glob '!**/node_modules/**' \
  --glob '**/package-lock.json' \
  --glob '**/yarn.lock' \
  --glob '**/pnpm-lock.yaml' \
  -e 'plain-crypto-js' \
  -e 'axios@1\.14\.1' \
  -e 'axios@0\.30\.4' \
  -e '"axios":\s*"(1\.14\.1|0\.30\.4)"' \
  <your-project-directory>

What to look for:

plain-crypto-js — your project is compromised
axios@1.14.1 or axios@0.30.4 — vulnerable version detected

How to Fix It

Following actions can help you:

1. Downgrade axios to the last safe version

npm install axios@1.14.0
yarn add axios@1.14.0
pnpm add axios@1.14.0

2. Reinstall all dependencies from scratch

rm -rf node_modules package-lock.json yarn.lock pnpm-lock.yaml
pnpm install

3. Redeploy your project

Do not skip this step. Your current production build may already contain the compromised code.

4. Rotate all secrets

Assume everything is leaked:

API keys
Database credentials
Auth tokens
Environment variables

❗ Rotate everything, do not wait.

Automated Scanner Script

Instead of running the command manually, you can use the scanner script from this blog post to check multiple projects at once.

Always preview a script before running it:

curl -s https://farzin.io/content/blog/axios-compromise/scan.sh | cat

Then run it:

curl -s https://farzin.io/content/blog/axios-compromise/scan.sh | bash

The script scans all lockfiles under a given root directory, reports each project as SAFE or INFECTED, and exits with a non-zero status code if any vulnerable dependencies are found , making it suitable for CI pipelines as well.

View the full script source

Closing Thoughts

The industry has spent years focused on code quality, performance, and developer experience. But the real risk is often the code we never wrote, dependencies we install and forget, buried inside node_modules, never audited again.

Supply chain attacks are no longer rare events. They are becoming a routine threat vector.

Lock your dependencies. Pin your versions. Audit your lockfiles regularly.

Stay paranoid. Stay safe ✨.

Share this post

Farzin.io