How to Detect and Remove the Axios Malware from Your Project

If your project may have installed the malicious Axios releases, treat it like a real incident.

The fastest path is to verify exposure, contain execution, and rotate anything sensitive that may have been available during the install window.

Start with verification

Use the tools you already have:

npm ls axios
npm ls plain-crypto-js
grep -n "axios@1.14.1\|axios@0.30.4\|plain-crypto-js@4.2.1" package-lock.json

If you are using pnpm or yarn, inspect the corresponding lockfile and workspace tree as well.

The goal is not just to know whether Axios appears in the repository.
The goal is to know whether the malicious versions were resolved and installed.

Treat the install window as suspicious

The public writeups from Aikido Security, Socket, Semgrep, and StepSecurity all point to the same response pattern: assume exposure until you have evidence otherwise.

Look for:

• installs that ran postinstall or other scripts
• temporary files created during package installation
• background child processes spawned by npm
• outbound traffic during dependency install windows

If you have EDR or SIEM visibility, focus on process lineage and network logs first. That is where a lot of the evidence will show up.

Contain first

Do not wait for a perfect forensic picture before you act.

Start containment with:

npm ci --ignore-scripts

Then rebuild from a clean lockfile and package manifest.

If the affected package executed on a machine or in CI where secrets were available, rotate:

• API keys
• npm tokens
• cloud credentials
• CI secrets
• signing keys

If you are unsure whether a secret was exposed, treat it as exposed.

What to check on endpoints

Search for:

• unusual curl, python3, or shell execution during dependency install
• files written to /tmp
• unexpected child processes from npm
• connections to attacker-controlled infrastructure

If you think an affected machine executed the package, assume the install path was a compromise path until proven otherwise.

What to keep in place after cleanup

Once you contain the incident, keep a few defensive defaults:

• pin dependencies more aggressively
• review lockfile changes in PRs
• keep npm ci --ignore-scripts in CI
• restrict outbound access from build jobs where possible
• document the response path for future dependency compromises

That makes the next incident much easier to handle.

Useful tools

The tools most often mentioned in the incident response guidance are:

• Snyk
• Socket
• Semgrep

Those tools do not replace response work, but they help you move faster.

---

Originally published on my blog.