Axios npm compromise traced to targeted social engineering attack, maintainer says
4 min. read 
Published on
The recent Axios npm compromise happened because an attacker socially engineered the project’s lead maintainer and gained access to his machine. It was not caused by a flaw in Axios itself. The attacker then used that access to publish two malicious versions to npm, exposing developers who performed fresh installs during the short window before the packages were removed.
Axios maintainer Jason Saayman said in the project’s post-mortem that the attacker gained access to the lead maintainer’s PC through “a targeted social engineering campaign and RAT malware.” He said that access let the attacker use npm credentials to publish the malicious releases.
Access content across the globe at the highest speed rate.
70% of our readers choose Private Internet Access
70% of our readers choose ExpressVPN
Browse the web from multiple devices with industry-standard security protocols.
Faster dedicated servers for specific actions (currently at summer discounts)
The malicious versions were [email protected] and [email protected]. According to the Axios post-mortem and GitHub advisories tied to downstream projects, those versions pulled in [email protected], a malicious dependency that deployed a cross-platform remote access trojan on macOS, Windows, and Linux.
What happened and why this incident matters
The attack window was short, but the potential impact was broad. Jason Saayman’s post-mortem says [email protected] went live at 00:21 UTC on March 31, 2026, [email protected] followed around 01:00 UTC, and the malicious versions were removed at 03:15 UTC. The injected dependency itself came down at 03:29 UTC.
That still mattered because Axios sits deep inside many software stacks. GitHub advisories for downstream packages said fresh installs without a lockfile could silently resolve to the bad Axios versions, which means some developers may have pulled the malware without directly choosing Axios themselves.
The maintainer also said the attacker deleted community reports from the compromised account while the incident was unfolding. That detail shows why supply chain attacks can move fast once an attacker controls a trusted maintainer account. Normal publishing activity can look legitimate until the wider community spots something wrong.
Why 2FA alone would not have saved this one
This case stands out because the attacker appears to have operated from the maintainer’s own environment. Socket reported that Saayman said the attacker had enough access to hijack browser sessions or cookies, which meant protections such as 2FA or OIDC-based publishing would not necessarily have stopped the malicious release once the machine itself was under attacker control.
After the incident, Saayman said all lead maintainer devices were wiped and all credentials were reset. He also said the project is moving toward a more secure release model, including immutable releases, better OIDC adoption for publishing, stronger GitHub Actions practices, and broader security improvements.
For developers and security teams, the message is clear. If you installed Axios during the affected window and resolved to 1.14.1 or 0.30.4, you should treat that machine as compromised, rotate secrets, and check for known command-and-control indicators. The maintainer specifically pointed users to sfrclak[.]com and 142.11.206.73:8000 as indicators to review in logs.
Affected versions and key facts
| Item | Details |
|---|---|
| Compromised Axios versions | 1.14.1 and 0.30.4 |
| Malicious dependency | [email protected] |
| Exposure window | Roughly 00:21 UTC to 03:15 UTC on March 31, 2026 |
| Platforms targeted | macOS, Windows, Linux |
| Main risk | Remote access trojan installed during package install |
| Known indicators | sfrclak[.]com, 142.11.206.73:8000 |
Source basis: Axios post-mortem and GitHub advisories.
What teams should do now
- Check lockfiles and dependency trees for
[email protected],[email protected], orplain-crypto-js. - Treat affected machines as compromised if those versions were installed during the exposure window.
- Rotate tokens, API keys, SSH keys, and any secrets exposed to that machine or CI runner.
- Review logs for traffic to
sfrclak[.]comor142.11.206.73on port 8000. - Pin Axios to a known clean version such as
1.14.0or0.30.3where applicable. - Tighten release workflows so maintainers do not publish from lightly protected personal environments.
FAQ
A targeted social engineering attack led to the compromise of the lead maintainer’s machine, which then gave the attacker access needed to publish malicious versions.
The compromised versions were [email protected] and [email protected].
No public source tied this incident to a flaw in Axios code. The incident stemmed from compromised maintainer access and a malicious dependency added during publishing.
Not necessarily. The maintainer and follow-up reporting said the attacker operated from the compromised machine and could hijack active sessions, which weakens protections that depend on trusted local access.
Read our disclosure page to find out how can you help VPNCentral sustain the editorial team Read more
Improve this guide
User forum
0 messages