On March 31, 2026, attackers used a compromised maintainer account to publish axios 1.14.1 and 0.30.4 to npm. Neither release changed axios code. Each added a hidden dependency that installed a remote access trojan. The lesson for attestation: a valid publisher login proved nothing about how, or from where, the release was built.
What happened?
GitHub's advisory GHSA-fw8c-xr5c-95f9, published March 31, 2026, classifies npm axios 1.14.1 and 0.30.4 as malware. Singapore's Cyber Security Agency advisory AD-2026-002, dated April 1, says attackers compromised the npm account of a primary axios maintainer and published unauthorised versions.
Per the CSA advisory, the releases contained a malicious dependency, plain-crypto-js 4.2.1, built to run a post-install payload that deploys a remote access trojan on Windows, macOS and Linux. The advisory also describes CI/CD pipeline bypass among the techniques. Safe versions named are axios 1.14.0 and 0.30.3.
What should you check?
GitHub's advice is blunt: a computer that has the package installed or running should be considered fully compromised. It adds that removing the package does not guarantee that all resulting malicious software is gone, and that secrets should be rotated from a different, uncompromised computer.
The CSA advisory lists the same steps: move to a safe version, remove plain-crypto-js, rotate credentials, and look for the published indicators and unusual outbound connections in CI logs.
Where is the attestation gap?
Think of three questions a consumer might ask of a release.
Who published it? The registry said a maintainer account did. That was true in the narrow sense.
How was it built? Build provenance records what entity built an artifact, with what process and from which inputs. SLSA describes provenance this way, and from level 2 it expects a hosted build platform to sign it. A release pushed by hand from a stolen login does not have to match the project's normal pipeline.
Does anything differ from the last release? A new dependency appeared that the project's source never listed. A comparison of dependency lists between versions would show it.
We do not know whether axios published provenance for earlier releases, and this post does not claim it did. The point is general. If a project normally publishes with provenance, a release without it is a signal. If it does not, you have no signal at all.
A constructed example
A team's lock file pins axios to 1.13.x, but a developer runs an update and gets 1.14.1 before anyone notices. The build runs a script that checks every new transitive dependency against an allow list and a minimum package age of seven days. plain-crypto-js, new and unknown, fails the check and the build stops before install scripts run on the CI runner.
How to check or apply this
- Search lock files and build logs for the two affected versions and for plain-crypto-js.
- If found, treat the host as compromised, rotate secrets from a clean machine and rebuild from known good sources.
- Pin dependencies with lock files and use frozen installs in CI.
- Block or review new transitive dependencies in pull requests, and consider a short minimum age for brand-new releases.
- Run installs in CI with install scripts disabled where your project allows it.
- Prefer packages that publish provenance, and alert when a package that normally does stops doing so.
- Protect maintainer and publisher accounts with phishing-resistant authentication and short-lived tokens.
Safeguard can scan dependencies, flag newly introduced packages through policies and gates in pull requests, and generate SBOMs so you can search all your products for an affected version.
What should you not conclude?
Do not conclude that attestations or provenance would have stopped this. They are signals that need a consumer who checks them. Do not conclude that axios is unsafe today either: the advisories name specific versions and safe replacements. The practical takeaway is to make unusual releases visible, so a human or a policy gets a chance to stop an install before scripts run.
Quick check
Which axios versions were malicious?
axios 1.14.1 and 0.30.4, according to the GitHub advisory and the Singapore CSA advisory. Safe versions named are 1.14.0 and 0.30.3.
Is updating to a safe version enough?
Not if the bad version was installed. Treat the machine as compromised, rotate secrets and rebuild from a clean state.
Sources
- GitHub Advisory GHSA-fw8c-xr5c-95f9, Malware in axios
- Cyber Security Agency of Singapore, Advisory AD-2026-002
- SLSA, Build track levels
Last reviewed: 18 October 2026.
