TL;DR: Malicious Axios versions published to npm used a compromised maintainer account, a postinstall hook, and a cross-platform RAT to target Windows, macOS, and Linux, according to Prophet Security. The incident shows why trusted dependency compromise is also an identity problem, because package integrity, maintainer trust, and exposed secrets now define the blast radius.
NHIMG editorial — based on content published by Prophet covering the malicious Axios supply chain attack: Supply Chain Alert: Malicious Axios Versions Published to npm March 31, 2026
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when a trusted npm package publisher is compromised?
A: When a trusted publisher is compromised, registry trust collapses because malicious code can arrive through a legitimate release path.
Q: Why do compromised open-source packages create such a large blast radius?
A: Because downstream consumers inherit trust in the publisher, not just the code.
Q: What do security teams get wrong about software supply chain risk?
A: They often focus on known vulnerabilities inside dependencies and miss the trust path that delivers the software.
Practitioner guidance
- Inventory package-publishing identities and tokens Map every maintainer account, npm token, CI/CD secret, and release credential that can publish or promote dependencies, then scope and rotate them with the same discipline used for privileged human access.
- Block automatic trust in lifecycle scripts Restrict or review postinstall and similar package lifecycle hooks in high-risk environments, especially on build agents and developer endpoints that can execute code during dependency installation.
- Correlate dependency installs with endpoint activity Look for package installation followed by suspicious child processes, persistence writes, or outbound connections from engineering laptops, CI jobs, and production images during the exposure window.
What's in the full analysis
Prophet's full article covers the operational detail this post intentionally leaves for the source:
- Indicator of compromise lists for malicious packages, hashes, and network infrastructure that security teams can load into detection workflows.
- Host-level hunt guidance for Windows, macOS, and Linux, including persistence artefacts and suspicious process patterns tied to the payload.
- Actionable remediation steps for lockfiles, dependency rollback, secrets rotation, and rebuild validation after suspected exposure.
- Context on how the malicious package spread through legitimate and attacker-operated infrastructure, which helps teams scope downstream risk.
👉 Read Prophet Security's analysis of the malicious Axios supply chain attack →
Malicious Axios supply chain attack: what it means for IAM teams?
Explore further
Trusted dependency compromise is now an identity event, not only a software event. When a maintainer account is abused, the attacker inherits the authority to distribute code through normal software channels. That makes publisher identity, token scope, and release workflow control part of the security boundary. Practitioners should treat package publishing as privileged access and govern it accordingly.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
A question worth separating out:
Q: Who is accountable when a malicious dependency enters a build pipeline?
A: Accountability is shared across engineering, security, and platform teams, but the control owner should be clear. Dependency intake, script execution, and publishing credentials are all governance points. In practice, the teams responsible for CI/CD, package policy, and non-human credential lifecycle must define who can approve, who can execute, and who can revoke.
👉 Read our full editorial: Malicious Axios versions show how supply chain trust turns into NHI risk