On March 31, 2026, the most popular HTTP library in the 📝JavaScript ecosystem was weaponized. Here's what happened, how we used 📝Artificial Intelligence (AI)-assisted development to assess and mitigate risk in under 30 minutes, and what you should do right now.

What happened to Axios

📝Axios gets over 100 million downloads per week. On March 31, an attacker hijacked the npm account of the library's primary maintainer and published two poisoned versions — `1.14.1` and `0.30.4` — that included a hidden malicious dependency called `plain-crypto-js`.

When installed, this dependency ran a `postinstall` script that:

Stole credentials from your environment — API keys, database passwords, cloud access tokens, `.env` files
Installed a Remote Access Trojan tailored to your operating system (macOS, Windows, and Linux variants)
Phoned home to a command-and-control server every 60 seconds
Deleted itself to cover its tracks

The attacker staged the malicious dependency 18 hours in advance to build registry credibility, then hit both Axios release branches within 39 minutes. npm pulled the packages about 3 hours later.

If your CI pipeline, 📝Docker build, or local `npm install` ran during that window and resolved to either of those versions, you may be compromised.

How we assessed our risk using Claude Code

When news broke, we didn't manually audit dozens of lockfiles across multiple repositories. We used 📝Claude Code (Anthropic's AI coding agent) to do it systematically, and you can do the same thing. Here's the exact workflow:

Step 1: Research the threat

We pointed Claude Code at the initial report and asked it to pull in everything it could find:

"Please review everything that you can find on the web as it regards the Axios NPM library delivering malware."

Claude Code fetched the advisory article, searched for corroborating sources from Snyk, Aikido, Huntress, SANS, and others, and synthesized the key facts: affected versions, the malicious package name, indicators of compromise, the attack timeline, and the C2 infrastructure details.

Having your AI agent do this research means you get a comprehensive picture in seconds rather than tabbing between a dozen blog posts.

Step 2: Assess exposure across all projects

In the same prompt, we asked Claude Code to check our actual installed packages:

"Please try to determine how at risk we are based on the npm packages that we have installed and when we installed them."

Claude Code automatically:

Found every `package-lock.json` and `yarn.lock` across all our repositories
Searched each one for axios version entries
Checked for the malicious `plain-crypto-js` package in lockfiles and `node_modules`
Checked the host machine for indicators of compromise (the macOS RAT binary, C2 port connections)

Result: one repo had axios (version 1.13.2, safe), zero traces of the malicious package, no IOCs on the machine. Clear picture, no ambiguity.

Step 3: Plan mitigations in plan mode

We asked Claude Code to create a hardening plan. It entered plan mode — a structured workflow where the AI explores your codebase, designs an approach, and presents it for approval before touching any code.

The initial plan included:

Pinning axios via Yarn resolutions to prevent transitive dependency drift
Disabling postinstall scripts globally (`--ignore-scripts`)
Adding security audit steps to CI
Cleaning up mixed lockfile state

Step 4: Peer review the plan with Codex

Before approving, we had Claude Code send the plan to OpenAI's Codex for a second opinion. This is a workflow pattern we use for all non-trivial plans — AI reviewing AI.

Codex caught a critical issue: the `--ignore-scripts` recommendation would break legitimate native binary installs for `esbuild`, `sharp`, `@sentry/cli`, and `unrs-resolver`. These packages rely on postinstall hooks to set up platform-specific binaries. Disabling scripts globally would have broken CI, Docker builds, and local development.

Claude Code revised the plan, kept what was sound, and dropped what would have caused harm.

Step 5: Implement and verify

With the revised plan approved, Claude Code made the changes:

Added a `resolutions` field in `package.json` to pin axios at the known-safe version
Pinned the package manager version via `packageManager` field
Removed a stale `package-lock.json` that shouldn't have existed alongside `yarn.lock`
Added `yarn audit` to the CI pipeline for ongoing visibility

Total time from "we heard about this" to "mitigations deployed": under 20 minutes.

What you should do right now

Check if you're affected
- Run these commands in each of your JavaScript/TypeScript projects: ```bash
Check your locked axios version
- grep -A2 '"axios"' package-lock.json yarn.lock 2>/dev/null
Check for the malicious package
- find node_modules -name "plain-crypto-js" -type d 2>/dev/null
macOS: Check for the RAT binary
- ls -la /Library/Caches/com.apple.act.mond 2>/dev/null
Check for C2 connections
- lsof -i :8000 2>/dev/null ```

If you have axios 1.14.1 or 0.30.4 installed

Assume compromise. This is not a drill.

Isolate the machine** — disconnect from network
Rotate every credential** the machine had access to: npm tokens, AWS keys, database passwords, API keys, SSH keys, CI/CD secrets, `.env` values
Check for RAT artifacts**: `/Library/Caches/com.apple.act.mond` (macOS), `%PROGRAMDATA%\wt.exe` (Windows), `/tmp/ld.py` (Linux)
Rebuild from clean state** — do not attempt to clean the infected system
**Audit CI/CD logs** for builds that ran during the March 31 00:21–03:29 UTC window

If you're not affected but use axios

Pin your axios version** to prevent future drift:

For npm (`package.json`):

```json

"overrides": { "axios": "1.13.2" }

```

For Yarn (`package.json`):

```json

"resolutions": { "axios": "1.13.2" }

```

Commit your lockfiles and use `npm ci` or `yarn install --frozen-lockfile` in CI. This is the single most important defense against supply chain attacks — it ensures your builds install exactly what was reviewed, not whatever is latest on the registry.
Add `npm audit` or `yarn audit` to your CI pipeline. Even as a non-blocking step, it surfaces known vulnerabilities on every build.
Don't blanket-disable postinstall scripts. It sounds like a good idea, but many legitimate packages (`esbuild`, `sharp`, `@sentry/cli`, Prisma) need them for native binary setup. You'll break your builds.

When to remove the pin

The axios resolution pin is a temporary measure. Remove it when:

The Axios maintainer account is confirmed re-secured with MFA
A clean post-compromise version is published and vetted
You've verified the new version's dependency tree

The pin blocks legitimate upstream security patches, so don't set it and forget it.

The bigger lesson

This attack exploited the weakest link in the npm ecosystem: a single maintainer account without adequate protection (no MFA, publishable via stolen token, no OIDC requirement enforced). The library's 100 million weekly downloads made it a high-value target.

Your defenses are:

Lockfiles, committed and enforced. If your CI runs `npm install` instead of `npm ci`, you're rolling the dice on every build.
Version pinning for critical transitive dependencies. Your app might not depend on axios directly, but something you depend on probably does.
Automated auditing in CI. Not as a gate (too many false positives in most projects), but as a signal.
AI-assisted rapid response. When the next supply chain attack drops — and there will be a next one — the speed at which you can assess exposure across all your projects matters. What took us 30 minutes with Claude Code would have taken hours manually.

The Axios compromise lasted 3 hours. The next one might last longer. Lock your dependencies, audit your builds, and know your exposure before someone else maps it for you.