DEV Community

Cover image for axios@1.14.1 Supply Chain Attack: What to Do Now
Wanda
Wanda

Posted on • Originally published at apidog.com

axios@1.14.1 Supply Chain Attack: What to Do Now

#javascript #news #npm #security

TL;DR

On March 30–31, 2026, axios versions 1.14.1 and 0.30.4 were compromised on npm via a malicious dependency that deployed a remote access trojan (RAT) to affected systems. Both versions are now unpublished. The last known safe version is 1.14.0. If you installed axios@1.14.1 or 0.30.4, treat the machine as compromised and rotate all credentials immediately.

Try Apidog today

What axios is and why this matters

axios has over 100 million weekly downloads on npm. It’s the HTTP client behind countless frontend frameworks, backend Node.js services, and enterprise apps. When a core package like this is compromised, the impact is massive—developers running npm install in a narrow window on March 30–31 unknowingly pulled malware.

This was not a theoretical supply chain risk. The attack was confirmed and delivered a multi-stage RAT capable of executing arbitrary commands, stealing system data, and persisting on infected machines.

If your team uses axios, and you leverage Apidog to design and test your HTTP integrations, you need to act before your next deploy.

Timeline of the attack

  • March 30, 2026 — 23:59:12 UTC: A malicious package plain-crypto-js@4.2.1 was published to npm by an account tied to nrwise@proton.me. A clean 4.2.0 version was published 18 hours earlier as a plausible typosquat of crypto-js.
  • March 31, 2026 — 00:05:41 UTC: Socket’s automated detection flagged plain-crypto-js@4.2.1 as malicious six minutes after publishing.
  • March 31, 2026 — shortly after midnight: axios@1.14.1 was published, depending on the malicious plain-crypto-js@4.2.1. This release was not in the official GitHub tags (latest legit tag: v1.14.0).
  • March 31, 2026 — morning: A GitHub issue (#10604) reported both axios@1.14.1 and 0.30.4 as compromised. Maintainers couldn’t immediately revoke access; the attacker had higher npm permissions.
  • March 31, 2026: Both compromised versions were unpublished. Maintainers revoked tokens, tightened publish controls, and investigated how a long-lived npm token was abused.

How the attack worked

The attacker exploited a long-lived npm token used in axios’s publishing workflow, likely after compromising a maintainer’s credentials. This allowed them to publish a malicious version outside the normal release process.

Key steps:

  • The new version added plain-crypto-js@4.2.1 as a dependency, camouflaging it as a legitimate utility.
  • The earlier clean version (4.2.0) established benign history to avoid suspicion.
  • Payload analysis:
    1. Stage 1: Malicious code executed at install time via npm lifecycle scripts, dropping a secondary payload.
    2. Stage 2: The secondary payload deployed a persistent RAT.
    3. Stage 3: The RAT enabled arbitrary shell command execution, exfiltrated environment variables and secrets, and sent system data to a remote server.

The RAT persists across reboots. Simply removing the npm package does NOT remove the RAT.

Am I affected?

You may be affected if:

  • You ran npm install axios or npm install (with axios in package.json) between March 30, 23:59 UTC and March 31, 2026 midday UTC.
  • Your node_modules/axios/package.json shows version 1.14.1 or 0.30.4.
  • Your package-lock.json or yarn.lock resolves axios to 1.14.1 or 0.30.4.

Check your environment:

# Check installed version
npm list axios

# Check lock file
grep '"axios"' package-lock.json | head -5

# Check for plain-crypto-js presence
npm list plain-crypto-js
ls node_modules/plain-crypto-js 2>/dev/null && echo "INFECTED" || echo "Not found"
Enter fullscreen mode Exit fullscreen mode

If plain-crypto-js exists in node_modules, you ran the malicious version.

What to do right now

1. Update axios immediately 

npm install axios@1.14.0
# Or pin to latest safe
npm install axios@latest
Enter fullscreen mode Exit fullscreen mode

Verify:

npm list axios
# Should show 1.14.0 or higher (once new clean versions are published)
Enter fullscreen mode Exit fullscreen mode

2. If you installed the compromised version

Treat the machine as compromised:

  • Rotate all secrets: API keys, DB credentials, SSH keys, cloud provider tokens, .env variables.
  • Check environment variables: RAT targets secrets in process env and filesystem.
  • Audit network connections: Review outbound traffic during the affected period for unknown IPs.
  • Scan for persistence: Inspect cron jobs, startup scripts, and systemd services created around the compromise.
  • Re-image the machine: On CI runners or production servers, re-install the OS. On developer laptops, rotate all credentials before considering the machine safe.

3. Audit your CI/CD pipelines

If your build pipeline ran npm install during the window, the CI environment may be compromised.

# Check build logs for affected timeframe
# Look for axios@1.14.1 in install output

# Verify current CI node_modules are clean
npm list axios plain-crypto-js
Enter fullscreen mode Exit fullscreen mode

Rotate any secrets available to CI: deployment keys, cloud credentials, registry tokens.

4. Verify your lock file

Lock files (package-lock.json, yarn.lock) should pin safe versions. If you find 1.14.1, regenerate:

# Remove and regenerate
rm package-lock.json
npm install
Enter fullscreen mode Exit fullscreen mode

Check that the new lock file resolves axios to a known safe version before committing.

Using Apidog to audit your axios API calls

If you use axios as your HTTP client, Apidog can help verify that your integration still works as expected after updating dependencies.

Steps:

  1. Update to axios@1.14.0.
  2. Import your existing API endpoints into Apidog.
  3. Run regression checks to ensure no request/response behavior has changed.

For example, use Apidog’s response assertions to detect unexpected fields or headers:

// Apidog post-response assertion
pm.test("Response is clean — no injected fields", () => {
    const body = pm.response.json();
    pm.expect(body).to.not.have.property('__injected');
    pm.expect(pm.response.headers.get('X-Injected-Header')).to.be.null;
});
Enter fullscreen mode Exit fullscreen mode

Running your test suite against the updated axios version in Apidog helps you establish a clean baseline before deploying.

Try Apidog free to set up HTTP client regression tests.

Why supply chain attacks on npm are hard to stop

The axios incident is part of a wider pattern:

  • event-stream (2018): Malicious payload targeting bitcoin wallets (8M downloads/week).
  • ua-parser-js (2021): Compromised to drop a cryptominer and password stealer.
  • node-ipc (2022): Maintainer added destructive code for specific geolocations.
  • xz utils (2024): Social engineering led to a backdoor in a core Linux utility.
  • axios (2026): Maintainer credentials compromised, RAT published via dependency.

Core problem: Trust is placed in publishing accounts, not just code. If a maintainer’s credentials are compromised, so is the package.

Mitigation strategies that help:

Measure What it does
Lock files (package-lock.json) Pin exact versions, prevent silent upgrades
npm audit in CI Flag known vulnerabilities before deploy
Socket.dev / Snyk Behavioral analysis—flag suspicious packages early
Two-factor auth on npm Harden credential compromise
Publish with short-lived tokens Limit exposure if a token leaks
Review lock files in PRs Catch dependency changes in code review

The axios team is moving to tighter publish controls, but broader ecosystem changes are needed.

Indicators of Compromise (IOCs)

From Socket’s analysis:

  • Malicious packages: plain-crypto-js@4.2.1, axios@1.14.1, axios@0.30.4
  • Publisher email: nrwise@proton.me
  • Behaviors: Network connections at install time, RAT persistence, environment variable exfiltration
  • Safe axios versions: 1.14.0 and below (except 0.30.4), 1.13.x, 1.12.x

If you suspect infection, report to npm security: security@npmjs.com and preserve relevant logs.

Conclusion

The axios 1.14.1 incident underscores that dependency security is an ongoing process, not a one-off audit. Pin your versions, use behavioral analysis tools like Socket in CI, rotate secrets if anything looks suspicious, and always review lock file changes in code review.

If you need to re-validate your API integration after an axios update, Apidog gives you the assertion, mocking, and regression testing tools to verify HTTP client behavior before you ship.

FAQ

Which axios versions are compromised?

axios@1.14.1 and axios@0.30.4. Both are unpublished. Use 1.14.0 or any in the 1.13.x, 1.12.x lines.

What does the malicious axios payload do?

It brings in plain-crypto-js@4.2.1, which delivers a multi-stage payload, including a RAT that can execute remote commands, exfiltrate secrets, and persist across reboots.

How do I know if I installed the compromised version?

Run npm list axios—if it shows 1.14.1 or 0.30.4, you’re affected. Also run npm list plain-crypto-js—if present, the malicious code ran.

Is it enough to just update axios?

No. While updating removes the malicious dependency, the RAT may already be installed. Rotate all secrets and audit for persistence mechanisms.

How did the attacker publish to npm?

They likely compromised a maintainer’s credentials and used a long-lived npm token with publish access. The axios team is tightening publish controls.

How is this different from a regular vulnerability?

A vulnerability is a flaw in existing code. A supply chain attack injects malicious code through a trusted publish channel. The compromised code was not in axios’s GitHub—it was injected at publish time.

How can I protect my projects from future supply chain attacks?

  • Use lock files
  • Run npm audit in CI
  • Add behavioral analysis (e.g., Socket.dev)
  • Enable 2FA on npm accounts
  • Use short-lived publish tokens
  • Audit lock file diffs in code review

Top comments (0)