Axios npm supply chain attack exposes how package trust fails

At a glance

What this is: This is a supply chain attack on the Axios npm package that used maintainer access to distribute malicious code and a remote access trojan across multiple operating systems.

Why it matters: It matters because dependency trust, package signing, and developer workstation credential exposure now sit on the same risk path as cloud and identity controls.

By the numbers:

• Expel first saw an alert from one of our custom detections about this hitting a customer at approximately 2026-03-31T00:50:00 UTC, about 22 minutes after the package went live.
• The malicious package was active from March 31 00:21 UTC to 03:15 UTC, creating a short but high-impact exposure window.

👉 Read Expel's analysis of the Axios npm supply chain attack

Context

Axios is a widely used JavaScript dependency, so a compromise at the package level can propagate far beyond the original maintainer account. In this case, the issue was not a vulnerability in the application itself but abuse of trusted software distribution, which is why supply chain control and identity governance become inseparable in modern development environments.

The central governance gap is that repository trust often outlives the assurance behind it. Once a maintainer account or release pipeline is compromised, malicious code can inherit the credibility of a normal update path, and any secrets present on the host or in adjacent tooling become part of the attacker’s reachable surface.

Key questions

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. The immediate failure is not only package integrity, but also the downstream assumption that a maintainer identity is a reliable control point. In practice, one hijacked publishing account can turn install-time trust into broad credential exposure.

Q: Why do package compromises often lead to credential theft?

A: Package compromises often lead to credential theft because developers and build hosts commonly store access tokens, cloud keys, and SSH material in reachable locations. Once code execution is achieved, attackers enumerate those secrets and reuse them as non-human identities in adjacent systems. That is why identity controls must extend into build and endpoint environments.

Q: How do security teams know if a package compromise is actually contained?

A: They should confirm three things: the bad version no longer appears in lockfiles, SBOM records no longer resolve to it, and running services no longer load it. If any one of those still matches, the compromise is not contained. Re-scan after remediation and require evidence from both code and runtime.

Q: Who is accountable when secrets are exposed through compromised infrastructure software?

A: Accountability usually spans infrastructure owners, identity teams, and incident responders because the risk crosses software patching, credential governance, and detection coverage. Frameworks such as NIST CSF and NIST SP 800-53 expect clear ownership for protection, monitoring, and remediation. If no team owns the exposed secrets, the incident will be repeated in another form.

Technical breakdown

How npm maintainer compromise becomes code execution

npm package ecosystems inherit trust from maintainers, release workflows, and dependency resolution. If an attacker gains maintainer access, they can publish a package version that looks legitimate to downstream installs. Because many build and developer environments automatically resolve updates, a malicious package can execute before security tools have time to inspect it. In this case, the attack also chained recursively through Axios dependencies, which is what turns a single compromised release into a multi-organisation event. The core failure is not only malicious code, but trust placed in the release path itself.

Practical implication: restrict who can publish, require strong release authentication, and verify dependency provenance before install.

How the RAT payload hid across operating systems

The malicious dependency delivered different execution paths for Windows, macOS, and Linux so it could survive heterogenous developer estates. On Windows it staged script execution through temporary files and a renamed PowerShell binary, which is a classic defence-evasion pattern. On macOS it used a file name that mimicked an Apple binary, while on Linux it downloaded and ran a Python script. These variations matter because defenders often key detections to one platform or one toolchain. Cross-platform payload design is a hallmark of supply chain tradecraft aimed at broad reach and fast execution.

Practical implication: hunt for platform-specific script execution and not just known malware hashes.

Why exposed secrets become the real downstream prize

Package compromise is rarely only about the initial payload. Once code executes in developer or build environments, attackers often enumerate local tokens, cloud keys, SSH material, and session artefacts that open larger environments than the infected host. That makes secret inventory and runtime containment part of supply chain defence, not a separate hygiene exercise. For identity teams, the important point is that exposed credentials created by a package compromise behave like stolen non-human identities until they are revoked, rotated, and audited across all systems that trusted them.

Practical implication: assume host-resident secrets are exposed and trigger revocation workflows immediately after confirmed package compromise.

Threat narrative

Attacker objective: The attackers aimed to gain code execution on developer and build systems and harvest credentials that could unlock wider enterprise environments.

1. Entry occurred when attackers abused maintainer access to publish a malicious Axios package update that downstream systems trusted as legitimate.
2. Escalation followed when the malicious dependency executed a remote access trojan and used platform-specific script execution to persist long enough for payload delivery.
3. Impact was broad credential and system exposure, including risk to npm tokens, AWS access keys, SSH private keys, and other host-stored secrets.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Supply chain trust is now an identity problem, not only a software integrity problem. When package maintainer access is abused, the attacker inherits the authority of a trusted release path and can turn a normal update into executable compromise. That makes publishing identity, signing identity, and developer workstation identity part of the same control surface. Practitioners should treat package provenance as an access-control question, not just a code-review issue.

Host-stored secrets are the most fragile asset in a package compromise. Once malicious code runs in a developer or CI environment, the practical prize is often npm tokens, cloud access keys, and SSH material already present on the system. This is the same governance failure seen in many NHI incidents: credentials are assumed safe because they are local, even though local execution is exactly where attackers want to land. The right mental model is exposed secrets as standing non-human identities.

Cross-platform payloads expose a detection gap in many build estates. The malicious Axios dependency used different execution paths for Windows, macOS, and Linux, which means one-platform telemetry will miss part of the attack picture. A more durable control stance combines package integrity checks, endpoint telemetry, and build-time restrictions on script execution. Practitioners should expect supply chain malware to adapt to the weakest operating system control, not the strongest one.

Short dwell time makes post-compromise review insufficient on its own. Expel’s detection window shows how quickly malicious releases can reach customers, which means the control objective is not just to notice compromise but to reduce the time between publication, execution, and revocation. That aligns with NHI governance more broadly: when credentials or package trust are abused briefly, the response must be immediate and automated. Practitioners should optimise for revocation speed, not forensic completeness alone.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• Forward pivot: The 52 NHI Breaches Analysis shows how exposed credentials and poor lifecycle control turn short-lived compromise into repeatable enterprise risk.

What this signals

Credential revocation speed is becoming the decisive control in software supply chain incidents. A package compromise that lasts minutes can still expose secrets that remain valid for months, so detection without automated revocation leaves the real risk intact. That is especially relevant for NHI programmes, where tokens and keys often outlive the incident that exposed them.

Build and developer environments should now be treated as identity surfaces. If a compromised dependency can execute in those environments, then local secrets, federated tokens, and service credentials become part of the attack path. Practitioners should connect endpoint telemetry, secret hygiene, and IAM response into one containment workflow rather than three separate processes.

Supply chain defence now depends on provenance plus lifecycle control. The ability to prove where a package came from is only half the problem if the credentials it touches are never revoked. Teams should expect more attacks that combine trusted software distribution with credential harvesting, especially as AI-assisted development increases dependency churn.

For practitioners

• Audit package publishing trust chains Review who can publish, approve, or transfer ownership for critical npm packages, and require phishing-resistant MFA plus release attestation for maintainers.
• Hunt for post-install script execution Search developer and CI endpoints for suspicious curl, PowerShell, Python, or temporary file execution associated with the compromise window.
• Revoke and rotate exposed credentials Assume npm tokens, AWS access keys, SSH private keys, and any other host-resident secrets on impacted systems are compromised until proven otherwise.
• Lock down build-time dependency execution Disable unnecessary post-install hooks, restrict outbound network access from build agents, and require dependency provenance checks before release promotion.
• Map package compromise to identity response playbooks Treat a compromised package as an identity incident, then trigger secret rotation, session invalidation, and maintainer account review together.

Key takeaways

• The Axios compromise shows how trusted package distribution can become a direct execution path for malware.
• The scale of risk is shaped by credential reuse, because host-stored secrets can remain exploitable long after the malicious package is removed.
• The strongest control response is to combine package provenance checks with immediate secret revocation and endpoint hunting.

Key terms

• Software Supply Chain Attack: A software supply chain attack targets the path software takes from source code to production. The attacker corrupts code, dependencies, build steps, or artifacts so that trusted delivery mechanisms spread malicious logic into environments that would otherwise reject direct intrusion.
• Remote Access Trojan: A remote access trojan is malware that gives an attacker interactive control over a compromised system after execution. It usually combines a loader, persistence and a command channel so the attacker can issue instructions, exfiltrate data or deploy additional payloads without repeatedly exploiting the target.
• Host-Resident Secrets: Host-resident secrets are credentials, tokens, keys, or certificates stored on endpoints, build agents, or developer machines. They are especially risky because any code execution on the host can turn local trust into broader enterprise access, making them a priority for rotation and revocation after compromise.

What's in the full analysis

Expel's full article covers the operational detail this post intentionally leaves for the source:

• Timeline analysis for the malicious Axios versions and the exact activity window to support hunts.
• Platform-specific command sequences for Windows, macOS, and Linux that defenders can use to validate telemetry.
• Operational remediation guidance for treating host-resident tokens, SSH keys, and AWS credentials as compromised.
• SOC response context showing how Expel built threat hunts and customer communications around the event.

👉 Expel's full post covers the attack timeline, platform-specific payloads, and remediation guidance.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity for practitioners who need to connect identity controls to real attack paths. It helps security teams build the lifecycle discipline required to reduce exposure across cloud, development, and runtime environments.