Notifications
Clear all
Topic starter
06/07/2026 9:42 am
TL;DR: Two malicious axios versions, 1.14.1 and 0.30.4, were published through compromised maintainer credentials and then used a postinstall payload to drop a cross-platform RAT that exposed secrets in developer and CI environments, according to Oligo Security. The incident shows why manifest scanning alone misses the actual attack path: execution at runtime is the control point that now matters.
NHIMG editorial — based on content published by Oligo Security: Malicious axios packages published via compromised credentials and the resulting runtime compromise
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: How should security teams handle malicious npm packages in CI pipelines?
A: Treat the event as both a supply chain compromise and a credential exposure incident.
Q: Why do malicious dependencies create more risk than a simple package mismatch?
A: Because the danger is often in the execution path, not just the declared dependency tree.
Q: What do security teams get wrong about dependency scanning?
A: They often assume a clean manifest means a clean environment.
Practitioner guidance
- Block install-time script execution in CI Set npm install to use --ignore-scripts in hardened build pipelines, then allow exceptions only for packages with explicit approval and runtime review.
- Treat affected hosts as credential exposure events If any workstation, runner, or container installed the malicious axios versions, rotate API tokens, SSH keys, cloud credentials, and environment variables that were present on that system.
- Audit package provenance and lock files Search manifests, lock files, and node_modules trees for [email protected] and the affected axios versions, then confirm whether the resolved package was executed on any build path.
What's in the full article
Oligo Security's full security research covers the operational detail this post intentionally leaves for the source:
- The exact malicious package versions, checksums, and indicators of compromise for incident validation.
- The runtime evidence chain showing how the postinstall payload dropped and executed a cross-platform RAT.
- The remediation steps for affected Node.js environments, including version pinning and pipeline hardening.
- The broader runtime protection explanation for spotting malicious package behaviour in real workloads.
Axios supply chain compromise: what runtime controls need to catch?
Explore further
06/07/2026 9:58 am
Package install is now an execution boundary, not a procurement step: Modern supply chain compromise works because software teams still treat dependency installation as a passive event. The axios case shows that install-time scripts can become the initial execution path, which means runtime inspection is no longer optional for package trust. The implication is that control ownership has to move from artifact review alone to execution-aware assurance.
A few things that frame the scale:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: Who is accountable when a compromised package exposes CI secrets?
A: Accountability is shared across the package publisher, the build platform owner, and the security team responsible for runtime controls. The practical question is whether the organisation allowed install-time execution, exposed reusable credentials on the host, and failed to detect the compromise before secrets were accessible.
👉 Read our full editorial: Malicious axios packages expose the runtime blind spot in supply chain security
