TL;DR

On March 30–31, 2026, axios versions 1.14.1 and 0.30.4 were compromised on npm with a malicious dependency that drops a remote access trojan (RAT) on infected machines. Both versions have been unpublished. The 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 happened

axios is one of the most widely used HTTP clients in the JavaScript ecosystem, with roughly 100 million weekly npm downloads. It is used in frontend apps, backend Node.js services, internal tools, and enterprise systems.

That makes an axios compromise high-impact. Developers who ran npm install during the affected window may have pulled malicious code onto their machines without realizing it.

This was not a theoretical supply chain risk. The compromised versions introduced a malicious dependency that deployed a multi-stage RAT capable of:

• Running arbitrary shell commands
• Reading environment variables and filesystem secrets
• Exfiltrating system data
• Persisting across reboots

If your project uses axios, verify your installed versions, clean your lock files, and rotate credentials if you installed the compromised releases.

Attack timeline

March 30, 2026 — 23:59:12 UTC

A malicious package named plain-crypto-js@4.2.1 was published to npm by an account using:

nrwise@proton.me

An earlier clean version, plain-crypto-js@4.2.0, had been published about 18 hours earlier. The package name appeared to imitate the legitimate crypto-js library.

March 31, 2026 — 00:05:41 UTC

Socket's automated malware detection flagged plain-crypto-js@4.2.1 as malicious, about six minutes after publication.

March 31, 2026 — shortly after midnight

axios@1.14.1 was published to npm and pulled in plain-crypto-js@4.2.1 as a dependency.

This release did not appear in the axios GitHub repository's official tags. The latest legitimate GitHub tag remained v1.14.0.

March 31, 2026 — morning

GitHub issue #10604 was opened publicly, reporting both axios@1.14.1 and axios@0.30.4 as compromised.

Axios maintainers confirmed they initially could not revoke the attacker's access because the compromised account had higher npm permissions than legitimate maintainers.

March 31, 2026

Both compromised versions were unpublished from npm:

axios@1.14.1
axios@0.30.4

The axios maintainers began revoking tokens, tightening publish controls, and investigating how a long-lived npm token was exploited.

How the compromise worked

The attack abused axios's npm publishing workflow.

A long-lived npm token had publish access alongside trusted publishing. After likely compromising maintainer credentials, the attacker used that token to publish malicious axios versions outside the normal release process.

The compromised axios versions introduced this dependency:

plain-crypto-js@4.2.1

Inside that dependency, Socket's analysis found a multi-stage payload.

Stage 1: Install-time execution

The malicious package executed code during installation using npm lifecycle scripts.

That means the payload could run when a developer or CI runner executed:

npm install

Stage 2: RAT deployment

The install-time script dropped a secondary payload: a remote access trojan.

The RAT opened a persistent backdoor on the infected machine.

Stage 3: Command execution and exfiltration

The RAT was capable of:

• Receiving commands from a remote C2 server
• Executing shell commands
• Reading environment variables
• Searching the filesystem for secrets
• Sending system data over the network

Because the RAT can persist across reboots, removing node_modules or updating axios is not enough if the malicious package already executed.

Am I affected?

You may be affected if any of the following are true:

• You ran npm install axios between approximately March 30, 23:59 UTC and March 31, 2026 midday UTC.
• You ran npm install for a project that already had axios in package.json during that window.
• Your installed axios version is 1.14.1 or 0.30.4.
• Your package-lock.json or yarn.lock resolves axios to 1.14.1 or 0.30.4.
• plain-crypto-js exists in your node_modules.

Check your project immediately.

# Check installed axios version
npm list axios

# Check for the malicious dependency
npm list plain-crypto-js

# Check whether the package exists locally
ls node_modules/plain-crypto-js 2>/dev/null && echo "INFECTED" || echo "Not found"

Check your lock file:

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

If plain-crypto-js is present, assume the malicious install script ran.

What to do now

1. Update axios

Install a safe version:

npm install axios@1.14.0

Or install the latest clean version once available:

npm install axios@latest

Verify the installed version:

npm list axios

Expected result:

axios@1.14.0

Or another confirmed clean version.

2. If you installed the compromised version, treat the machine as compromised

Do not handle this like a normal dependency update.

If axios@1.14.1, axios@0.30.4, or plain-crypto-js@4.2.1 was installed, rotate all credentials accessible from that machine.

Rotate:

• API keys
• Database credentials
• SSH keys
• Cloud provider tokens
• npm tokens
• GitHub tokens
• CI/CD deployment keys
• .env secrets
• Any credentials stored in local config files

Also check:

• Environment variables
• Shell history
• Local secret files
• SSH config and keys
• Cloud CLI credentials
• Package manager auth tokens

3. Hunt for persistence

The RAT may persist after the package is removed.

Check for suspicious entries created around the compromise window.

Cron jobs

crontab -l
ls -la /etc/cron.* /etc/crontab 2>/dev/null

systemd services

systemctl list-unit-files --type=service
systemctl list-timers

Startup scripts

ls -la ~/.config/autostart 2>/dev/null
ls -la ~/.bashrc ~/.zshrc ~/.profile 2>/dev/null

Suspicious network activity

lsof -i -P -n
netstat -tunap 2>/dev/null

If the affected machine is a CI runner or production server, re-image it instead of trying to clean it manually.

For developer laptops, rotate credentials first, then investigate persistence before trusting the machine again.

4. Audit CI/CD pipelines

If your CI system ran npm install during the affected window, assume the CI environment may have executed the malicious payload.

Search build logs for:

axios@1.14.1
axios@0.30.4
plain-crypto-js

Verify current dependencies:

npm list axios plain-crypto-js

Rotate CI-accessible secrets:

• Deployment keys
• Cloud provider credentials
• npm tokens
• GitHub tokens
• Container registry credentials
• Environment variables used in builds

If your CI runners are long-lived, rebuild them from a clean image.

5. Regenerate compromised lock files

If your lock file pins a compromised axios version, regenerate it.

For npm:

rm package-lock.json
rm -rf node_modules
npm install

Then verify:

npm list axios
npm list plain-crypto-js

Before committing, inspect the lock file diff and confirm axios resolves to a safe version.

Using Apidog to validate axios API behavior

After updating axios, you should verify that your API integrations still behave as expected.

If your app uses axios to call internal or external APIs, use Apidog to run regression checks against your API requests and responses.

A practical workflow:

1. Update axios to a safe version.
2. Import or organize your API endpoints in Apidog.
3. Run your existing API test cases.
4. Add assertions for response shape, headers, and status codes.
5. Compare behavior against your expected clean baseline.
6. Run the same checks before deploying.

Example post-response assertion:

// 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;
});

You can also assert exact response fields:

pm.test("User response has expected fields", () => {
  const body = pm.response.json();

  pm.expect(body).to.have.property("id");
  pm.expect(body).to.have.property("email");
  pm.expect(body).to.not.have.property("token");
});

And verify status codes:

pm.test("Request succeeds", () => {
  pm.response.to.have.status(200);
});

This gives your team a documented clean baseline after the dependency update and before production deployment.

Why npm supply chain attacks are hard to prevent

The axios compromise follows a known pattern: attackers target trust in package publishing, not only vulnerabilities in code.

Previous supply chain incidents include:

• event-stream in 2018: malicious maintainer payload targeting bitcoin wallets.
• ua-parser-js in 2021: compromised package dropping a cryptominer and password stealer.
• node-ipc in 2022: destructive code targeting Russian and Belarusian IPs.
• xz utils in 2024: long-running social engineering campaign to backdoor a core Linux compression library.
• axios in 2026: compromised npm publish access used to distribute a RAT through a malicious dependency.

The common issue: if a trusted publishing account is compromised, the attacker can publish code under a package developers already trust.

Practical mitigations

Use multiple layers of defense. No single control is enough.

Add dependency checks to CI:

npm audit
npm list axios plain-crypto-js

Fail builds if compromised versions appear:

npm list axios | grep -E "axios@(1\.14\.1|0\.30\.4)" && exit 1 || true
npm list plain-crypto-js && exit 1 || true

For lock file review, make dependency changes visible in pull requests and require review for unexpected package additions.

Indicators of Compromise

Per Socket's analysis, watch for the following.

Malicious packages

plain-crypto-js@4.2.1
axios@1.14.1
axios@0.30.4

Publisher email

nrwise@proton.me

Suspicious behavior

• Network connections during npm install
• RAT persistence
• Environment variable access
• Secret exfiltration
• Unknown startup scripts, cron jobs, or services

Safe axios versions

axios@1.14.0
axios@1.13.x
axios@1.12.x

Also safe: versions below 1.14.1, except 0.30.4.

If you suspect infection, preserve logs and report it to npm security:

security@npmjs.com

Conclusion

The axios compromise shows why dependency security must be continuous.

For affected projects:

1. Check installed axios versions.
2. Check lock files.
3. Search for plain-crypto-js.
4. Update to a safe axios version.
5. Rotate credentials if the malicious package was installed.
6. Audit developer machines and CI runners.
7. Rebuild compromised environments where appropriate.
8. Add dependency and lock file checks to CI.

After updating axios, use API regression tests to confirm your HTTP client behavior is still correct before shipping.

FAQ

Which axios versions were compromised?

axios@1.14.1 and axios@0.30.4.

Both were unpublished from npm. The safe version is 1.14.0, along with the 1.13.x and 1.12.x lines.

What does the malicious payload do?

The compromised axios versions pull in plain-crypto-js@4.2.1, which deploys a multi-stage payload including a remote access trojan.

The RAT can execute commands from a remote C2 server, exfiltrate environment variables and secrets, and persist across reboots.

How do I know if I installed the compromised version?

Run:

npm list axios
npm list plain-crypto-js

If axios resolves to 1.14.1 or 0.30.4, you are affected.

If plain-crypto-js is present, the malicious package was installed.

Is updating axios enough?

No.

Updating axios prevents future installs of the malicious dependency, but it does not guarantee the RAT has been removed.

If you installed the compromised version, rotate credentials and audit the machine for persistence.

How did the attacker publish the package?

The attacker likely compromised maintainer credentials and used a long-lived npm token with publish access.

The axios team investigated the publishing workflow and began tightening controls.

How is this different from a normal vulnerability?

A normal vulnerability is a flaw in legitimate code.

A supply chain attack introduces malicious code through a trusted publishing channel.

In this case, the compromised code was not part of the official axios GitHub repository. It was injected through npm publishing.

How can I protect future projects?

Use:

• Lock files
• CI dependency checks
• npm audit
• Behavioral analysis tools like Socket.dev
• npm 2FA
• Short-lived publish tokens
• Pull request reviews for lock file changes
• Clean rebuilds for CI runners
• Fast credential rotation when compromise is suspected