On 31 March 2026, malicious releases of Axios reached npm through a compromised maintainer account. The maintainer’s incident report identifies versions 1.14.1 and 0.30.4, with an injected dependency named plain-crypto-js@4.2.1.
The report says the payload installed a remote-access trojan and the malicious releases were available for about three hours. That is enough to warrant checking developer machines and build systems that installed dependencies during the affected period. It does not establish that every Axios user was compromised.
Establish whether installation occurred
Start with lockfiles, build logs and dependency caches. Check direct and transitive dependencies, since a package can be present without appearing in the application’s top-level dependency list.
Record which machine ran the installation and which credentials were available to it. A developer laptop and an automated build runner may have very different access to production systems.
You can inspect the currently installed dependency tree with:
npm ls axios plain-crypto-js --allThis is a starting point. A clean result today does not prove that an affected version was never installed, and an entry in a historical lockfile alone does not prove that the payload executed.
Treat suspected exposure as an incident
If the evidence indicates an affected installation, involve whoever owns incident response. Isolate the machine, preserve relevant logs and rotate exposed credentials from a trusted environment. Review the build runner’s access as well as the application account’s access.
Replacing the package does not remove malware that has already run or revoke credentials it may have accessed. Follow the maintainer’s remediation references alongside your organisation’s incident process. Check current security advisories before selecting a replacement version; an older release is not a permanent security recommendation.
Review how dependencies reach production
Keep lockfiles under review and make automated builds reproduce the agreed dependency tree. Limit secrets in installation and build jobs to what those jobs need. Review whether package lifecycle scripts are required and how exceptions are approved.
Dependency scanning helps identify known issues. It cannot guarantee that a newly published package is safe. Add review of unexpected dependencies and publishing changes, especially in packages with access to your build environment.
Keep the response usable
For a South African business, write down who can pause deployments, revoke credentials and assess whether personal information may have been affected. Test that process before an urgent update is needed.
The useful lesson is a narrower, reviewable path from downloaded code to production. Speak to webrack if you need help reviewing that path for your application.