Topic starter
23/06/2026 9:15 pm
TL;DR: A compromised axios maintainer account published two malicious npm versions that installed a cross-platform RAT within minutes of npm install, affecting a library with roughly 100 million weekly downloads and over 174,000 dependents, according to Orca Security. Trust controls fail when legacy publishing paths and postinstall execution remain available alongside modern provenance.
Editorial analysis by NHI Mgmt Group, based on content published by Orca Security: “Supply Chain Attack on Axios Delivers Cross-Platform RAT via Compromised npm Account”.
Key questions
Q: What breaks when npm packages can still run postinstall hooks during install?
A: Postinstall hooks turn dependency installation into code execution, which means a package can be trusted as a library but behave like malware at install time.
Q: Why do legacy publishing tokens create supply chain risk after trusted publishing is enabled?
A: Because legacy tokens preserve an alternate path to publish releases without the workflow identity and provenance that trusted publishing is meant to enforce.
Q: How should teams respond when a package or maintainer account is compromised?
A: Assume any reachable credentials may be exposed, then rotate broadly across vaults, cloud secret managers, and developer tooling.
Practitioner guidance
- Eliminate legacy npm publishing paths Remove long-lived npm access tokens where trusted publishing is already available, and require a single release path with OIDC-backed provenance only.
- Block automatic install-time script execution Use npm install --ignore-scripts in CI/CD where feasible, then allow scripts only for packages that have been explicitly reviewed and justified.
- Review package manifests for hidden execution Inspect dependency changes for postinstall hooks, runtime-only packages, and phantom dependencies that do not appear in the application import graph.
Bottom line: The incident was a maintainer-account compromise, not a flaw in axios source code, which is why release identity and publishing path control matter more than code review alone.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
25/06/2026 2:27 am
Legacy publishing tokens are the real trust gap here: Trusted publishing did not fail as a concept, but it failed as a governance boundary because an older token still existed beside it. That means release identity was split across two pathways with different assurance levels. The practical lesson is that publishing assurance is only as strong as its weakest remaining authentication path.
A few things that frame the scale:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: When should teams trust package provenance over dependency version numbers?
A: Only when the provenance is tied to a known workflow, the package was published through the expected release channel, and there is a corresponding source change to review. Version numbers alone do not prove legitimacy. Provenance should be used as a gating control, not an after-the-fact label on a release.
👉 Read our full editorial: Axios maintainer compromise shows how npm trust fails
This post was modified 1 day ago by NHI Mgmt Group