Notifications
Clear all
Topic starter
02/08/2026 11:51 am
TL;DR: A stolen npm maintainer account let attackers publish malicious axios versions that pulled in a hidden dependency, deployed a cross-platform remote access trojan, and self-destructed after execution, according to Aikido. For identity and software supply chain teams, the lesson is that trusted publishing, token hygiene, and dependency age controls now sit on the same risk path.
NHIMG editorial — based on content published by Aikido covering the axios npm compromise: axios compromised on npm, maintainer account hijacked, RAT deployed
By the numbers:
Questions worth separating out
Q: What breaks when a package maintainer account is compromised?
A: When a maintainer account is compromised, the attacker inherits trusted publishing rights and can turn legitimate release channels into malware distribution paths.
Q: Why do maintained software identities need IAM-style governance?
A: Because package publishers, CI tokens, and trusted publishing bindings function like non-human identities with privileged actions and lifecycle risk.
Q: How do security teams know if dependency controls are actually working?
A: Look for whether build systems prevent unauthorised version drift, whether package provenance is checked before install, and whether secret-handling code is isolated from broad application reach.
Practitioner guidance
- Separate release identity from source-code identity Require package publication through trusted publisher bindings and distinct approval paths so a stolen maintainer account cannot directly push registry releases.
- Enforce minimum package age in CI/CD Block newly published dependencies until they have aged beyond a defined threshold, especially for transitive packages introduced during install.
- Preserve install-time evidence before cleanup occurs Capture package install logs, dependency trees, and build telemetry centrally, because self-deleting droppers can remove local filesystem evidence after execution.
What's in the full analysis
Aikido's full article covers the operational detail this post intentionally leaves for the source:
- Exact package and filesystem indicators of compromise for macOS, Windows, and Linux hosts
- Step-by-step checks for package-lock files, installed dependencies, and hidden dropper directories
- Concrete remediation commands for pinning safe axios versions and removing the malicious dependency
- Safe Chain policy details for blocking newly published packages before they execute
👉 Read Aikido's analysis of the axios npm maintainer hijack and RAT deployment →
Axios npm compromise and maintainer hijack: what should teams change?
Explore further
02/08/2026 1:00 pm
Publisher identity is now a security control, not an administrative detail. This incident worked because the attacker controlled the identity used to publish software, not because the package code itself looked obviously malicious. That is exactly the kind of control gap that NHI governance is meant to close. When release authority is treated as a low-friction operational task, tokens and maintainer accounts become high-value NHI assets with weak lifecycle oversight.
A few things that frame the scale:
- axios has ~100 million weekly downloads, according to The State of Secrets in AppSec.
- Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to The State of Secrets in AppSec.
A question worth separating out:
Q: What should teams do after a malicious npm package has run in CI/CD?
A: Contain the build environment, assume secrets on that system are exposed, and rebuild from a known-good baseline before restoring access. Then rotate npm tokens, cloud keys, SSH keys, and pipeline secrets that were reachable from the compromised host. The goal is to remove attacker persistence before any cleanup can be trusted.
👉 Read our full editorial: Axios npm compromise shows how maintainer hijack becomes malware delivery
