Post Mortem: axios NPM supply chain compromise

Two malicious versions of the popular Axios library were published to npm after a lead maintainer's account was compromised, delivering a Remote Access Trojan (RAT) to affected systems.
Post Mortem: axios npm supply chain compromise #10636
Description
Date: March 31, 2026
Author: Jason Saayman
Status: Remediation in progress
On March 31, 2026, two malicious versions of axios (1.14.1 and 0.30.4) were published to the npm registry through my compromised account. Both versions injected a dependency called [email protected] that installed a remote access trojan on macOS, Windows, and Linux.
The malicious versions were live for about 3 hours before being removed.
Are you affected?
Check your lockfile:
grep -E "axios@(1\.14\.1|0\.30\.4)|plain-crypto-js" package-lock.json yarn.lock 2>/dev/null
If anything comes back, treat that machine as compromised:
- Downgrade to
[email protected](or0.30.3for 0.x users) - Delete
node_modules/plain-crypto-js/ - Rotate every secret, token, and credential on that machine
- Check your network logs for connections to
sfrclak[.]comor142.11.206.73on port 8000 - If this happened on a CI runner, rotate any secrets that were injected during the affected build
If you were already pinned to a clean version and didn't run a fresh install between 00:21 and 03:15 UTC on March 31, you're fine.
What happened
The attacker gained access to the lead maintainer's PC through a targeted social engineering campaign and RAT malware. This gave them access to the npm account credentials, which they used to publish the malicious versions.
The attack followed patterns documented in similar campaigns targeting open source maintainers.
Resolution
Complete wipe of all lead maintainer devices as well as resetting of all credentials. This includes all accounts irrespective of platform, both personal and all other capacities.
What's changing
To prevent this from happening again, these are the changes being made:
| Action | Type | |---|---| | Reset of all devices and credentials | Prevention | | Immutable release setup | Prevention | | Proper adoption of OIDC flow for publishing | Prevention | | Improvement of overall security posture | Prevention | | Updating of all GitHub actions to adopt best practices | Prevention |
Attack Timeline
- About 2 weeks before March 31: social engineering campaign initiated against the lead maintainer
- March 30, 05:57 UTC:
[email protected]published to npm - March 31, 00:21 UTC:
[email protected]published with[email protected]injected - March 31, around 01:00 UTC:
[email protected]published with the same payload; first external detections - March 31, around 01:00 UTC: community members file issues reporting the compromise. The attacker deletes them using the compromised account.
- March 31, 01:38 UTC: axios collaborator DigitalBrainJS opens PR to deprecate the compromised versions and contacts npm directly
- March 31, 03:15 UTC: malicious versions removed from npm
- March 31, 03:29 UTC:
plain-crypto-jsremoved from npm
Lessons learned
- Publishing directly from a personal account was a risk that could have been avoided. The OIDC flow and immutable release setup we are now adopting should have been in place before this happened.
- There was no automated way to detect an unauthorized publish. Detection depended entirely on the community noticing.
- Open source maintainers with high-impact packages are active targets for sophisticated social engineering. Hyper vigilance is needed both on the registry and in a personal capacity.
Source: Hacker News













