How to Detect and Remove the Axios Malware from Your Project

If your project installed the malicious Axios releases, do not treat it like a routine dependency update. Treat it like a containment problem.

The reports from Aikido Security, Socket, and Semgrep all point to the same operational advice: assume exposure, verify quickly, and rotate anything sensitive that may have been present during install.

Immediate checklist

Start here:

1. identify whether the affected versions reached your lockfiles
2. check CI logs for installs that ran install scripts
3. inspect developer machines that used the repository during the exposure window
4. rotate tokens, API keys, and secrets used in that environment
5. remove the malicious package versions from the dependency graph
6. rebuild from a clean lockfile
7. monitor for suspicious outbound network traffic

Do not wait for a perfect forensic picture before taking the first containment steps.

Find the package in your dependency tree

Use the tools you already have:

npm ls axios
npm ls plain-crypto-js

If you are using a lockfile, inspect it directly:

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

If you are in a pnpm or yarn workspace, search the corresponding lockfile the same way.

The point is not just to know whether Axios exists in the project. The point is to know whether the malicious versions were resolved and installed.

Reinstall safely

For CI, use install modes that avoid script execution:

npm ci --ignore-scripts

That is not a magic shield, but it removes the most dangerous install-time behavior from your automated builds.

If the repository is already in a questionable state, do a clean reinstall from a trusted lockfile and package manifest.

Rotate secrets

This is the part teams skip too often.

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

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

If you are unsure whether a secret was exposed, treat it as exposed. That is the safer assumption.

Look for signs of execution

StepSecurity documented network and process behavior that can help with triage:

• install-time execution
• temporary files in /tmp
• background child processes
• outbound traffic to attacker infrastructure

Search your logs for unusual outbound requests during dependency installation windows.

If your EDR or SIEM tracks process lineage, look for:

• npm spawning shell commands
• shell commands spawning curl or python3
• temporary files created during install

Block the obvious paths

If you are still in the response window, harden installs immediately:

• set npm ci --ignore-scripts in CI
• require lockfile review for dependency changes
• pin versions more aggressively
• restrict outbound network access from build jobs where possible

This will not undo the compromise, but it lowers the chance of a second incident during cleanup.

When to consider the incident closed

Only call it closed when all of the following are true:

• affected versions are removed from dependency resolution
• rebuilt artifacts come from a clean install path
• secrets from the exposure window are rotated
• endpoints are clean of the reported process and network artifacts
• the team has documented what happened and what control failed

Useful tools

The reporting around this incident repeatedly points to the same class of tools:

• Snyk
• Socket
• Semgrep

Those tools do not replace incident response, but they make dependency review and detection faster.

Practical default

If you only remember one thing, remember this:

when an install-time compromise is possible, dependency hygiene is part of security response, not just build hygiene.

Sources

• Aikido Security
• Socket
• Semgrep
• StepSecurity