Axios supply chain compromise shows how hijacked npm identities spread RATs

At a glance

What this is: This is a supply chain incident analysis of poisoned axios npm releases that used a compromised maintainer identity to deliver a cross-platform RAT through a hidden dependency.

Why it matters: It matters because package publisher identity, CI trust boundaries, and developer endpoint controls now sit on the same attack path as code review and dependency hygiene.

By the numbers:

• axios is the most popular JavaScript HTTP client library with over 100 million weekly downloads.

👉 Read StepSecurity's analysis of the axios npm supply chain compromise

Context

npm supply chain attacks succeed when trust is placed on package names, maintainer accounts, and publish pathways rather than on runtime behaviour. In this case, the primary failure was identity compromise at the package maintainer level, followed by malicious dependency injection and self-deleting malware that obscured post-install evidence. For identity security teams, the relevant question is not just whether dependencies are scanned, but whether publisher identity, token provenance, and install-time egress are governed together.

Axios is a widely used JavaScript dependency, which makes its release channel an attractive target for attackers seeking broad downstream exposure. The attack shows how non-human identity controls, especially publisher accounts, tokens, and CI-linked release trust, can be bypassed when long-lived credentials are stolen or abused. That is a genuine NHI governance problem as much as a software supply chain problem.

The starting position here is unfortunately typical of modern supply chain abuse: a trusted maintainer identity was the entry point, and the malicious payload was engineered to blend into routine package installation activity.

Key questions

Q: What breaks when package publishing identities are compromised?

A: When publishing identities are compromised, the attacker can release malicious packages that inherit the trust of a real project. That breaks provenance, invalidates normal review assumptions, and can turn a routine dependency update into code execution. Teams should treat registry accounts, publish tokens, and CI bindings as privileged identities with lifecycle controls and alerting.

Q: Why do hidden dependencies make npm supply chain attacks so dangerous?

A: Hidden dependencies let attackers introduce executable behaviour without changing the visible application code. A package can look legitimate in source review while still running install-time payloads, reaching command-and-control infrastructure, or staging second-stage malware. That means dependency governance must cover metadata, install hooks, and runtime network behaviour, not just file diffs.

Q: How do you know if package security controls are actually working?

A: Look for fewer unexpected publishes reaching build systems, lower rates of install-time outbound connections, and measurable reductions in secret exposure during pipeline execution. Strong controls should also produce clear denial events when packages attempt to fetch credentials, contact external endpoints, or install from unauthorised sources.

Q: Who is accountable when a malicious package reaches production systems?

A: Accountability usually sits across security, engineering, and platform operations. Engineering controls the dependency choices, security defines the detection and response requirements, and platform teams govern build pipelines and package trust policies. Frameworks such as NIST CSF, NIST 800-53, and MITRE ATT&CK support shared ownership of prevention, detection, and response.

Technical breakdown

Maintainer account hijack and trusted publishing break

The attack begins when a maintainer account is compromised and used to publish malicious releases that appear legitimate in the registry. In normal npm workflows, cryptographically bound publishing through GitHub Actions and OIDC creates a provenance signal, because the release is tied to a verified workflow rather than a manual token-based publish. Here, that trust chain was broken. The result is not just a malicious package, but a release that inherits the reputation of a real project while bypassing the controls that should distinguish human-approved publishing from stolen-identity publishing.

Practical implication: enforce provenance checks on package publication and alert on releases that diverge from expected trusted-publisher patterns.

Postinstall scripts as runtime execution points

A package postinstall script executes during dependency installation, which makes it a privileged runtime event rather than a passive metadata field. Attackers use that step to trigger code outside the application source tree, often before developers notice the package has been added. In this case, the hidden dependency exists only to run setup.js, which drops a RAT and then removes its own artifacts. That pattern is dangerous because most software review processes focus on source code, while install hooks can execute independently of the application logic.

Practical implication: treat install hooks as executable content and restrict or block postinstall behaviour in high-trust build and developer environments.

Self-deleting malware and anti-forensics in package ecosystems

The malicious package was designed to erase the obvious evidence after execution by deleting setup files, replacing package metadata, and hiding its own payload trail. This is a classic anti-forensics pattern adapted for the Node.js ecosystem: the package exists long enough to execute, but not long enough to support straightforward inspection afterward. Because the malware also used platform-specific payloads and command-and-control callbacks, the compromise extended beyond the registry into endpoints and CI runners. That combination makes detection by static scanning alone unreliable.

Practical implication: add egress monitoring, process telemetry, and post-install detection on both CI runners and developer endpoints.

Threat narrative

Attacker objective: The attacker wanted to convert a trusted software dependency into a delivery mechanism for endpoint compromise, credential theft, and downstream supply chain reach.

1. Entry occurred through a compromised npm maintainer identity that was used to publish poisoned axios releases under a trusted package name.
2. Credential access and abuse were enabled by a long-lived token path that bypassed the normal OIDC-trusted publishing flow and let the attacker stage a hidden dependency.
3. Impact followed when the postinstall hook dropped a cross-platform RAT, phoned home to command-and-control infrastructure, and attempted to remove forensic evidence.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Vercel Context.ai OAuth Supply Chain Breach — Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.

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

NHI Mgmt Group analysis

Trusted publisher identity is now a control plane, not a metadata field. The axios compromise shows that package provenance is only as strong as the identity used to publish it. When a maintainer token or account is hijacked, the attacker inherits distribution trust, not just repository access. Identity governance teams should treat software publishing accounts, OIDC bindings, and registry privileges as high-value NHI assets that require lifecycle controls, not ad hoc administration.

Install-time execution is the point where software supply chain risk becomes endpoint risk. A hidden dependency with a postinstall script bypasses the assumption that package review equals runtime safety. That matters for both CI runners and developer workstations, because the same package can execute different payloads across platforms. The governance gap is the absence of install-time policy and egress enforcement at the moment a package turns into code.

Self-erasing malware creates a verification trust gap that static review cannot close. When a package deletes its own scripts and rewrites metadata, retrospective inspection loses evidentiary value. This is the named concept this incident sharpens: the verification trust gap between trusted registry state and actual runtime behaviour. Practitioners need to compensate with behavioural telemetry, provenance checks, and immutable install logs.

Supply chain security now depends on identity lifecycle discipline across humans and machines. The same controls that matter for human access, such as token rotation, privilege scoping, and account recovery, are relevant for maintainer identities and automation credentials. Where publishing pathways still rely on long-lived secrets, attackers only need one compromise to turn a trusted build channel into malware distribution. The practical conclusion is to govern publisher identities with the same rigor as privileged admin accounts.

The category is moving from package hygiene to runtime assurance. Static scanning can help, but it is insufficient when attackers pre-stage dependencies, split payloads by platform, and self-delete after execution. The broader market signal is that NHI governance, provenance enforcement, and endpoint observability are converging into a single control problem. Teams that still treat dependency risk as a pure SCA issue will miss the operational attack path.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, 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.
• That confidence gap reinforces why publisher identities, tokens, and delegated access should be governed as first-class NHI assets, not treated as background plumbing.

What this signals

The practical lesson for enterprise programmes is that software supply chain events increasingly look like identity incidents. Publisher accounts, registry tokens, and OIDC bindings function as non-human identities, and they need the same rotation, provenance, and offboarding discipline as service accounts or API keys.

Verification trust gap: this incident shows the distance between a trusted registry record and what actually executes on install. Organisations should pair dependency policy with runtime telemetry, because self-deleting malware can defeat retrospective package inspection and still compromise endpoints.

Teams that already run secrets management, CI egress control, and developer device telemetry have the right control surfaces, but they need to connect them. The next maturity step is to treat package provenance, build identity, and install-time behaviour as one governed workflow rather than three separate risks.

For practitioners

• Enforce trusted publishing for package releases Require cryptographically verifiable publishing paths such as OIDC-linked workflows for all internal and third-party package releases, and alert on any manual publish that diverges from the approved pattern.
• Block or review install hooks Prevent postinstall scripts from running in high-trust pipelines unless the package and maintainer identity have passed explicit approval, because install-time code execution is where the compromise becomes active.
• Add egress controls to CI and developer devices Use outbound allowlisting and DNS or process telemetry to detect package installs that reach unknown command-and-control infrastructure, especially when the package later deletes its own artifacts.
• Search for affected versions across the estate Inventory every repository, pull request, and enrolled device where [email protected] or [email protected] was introduced so blast radius, containment, and reimaging decisions can be made quickly.
• Rotate maintainer and publishing credentials Treat package registry tokens, maintainer accounts, and CI secrets as privileged identities and rotate them immediately when publication provenance changes or suspicious releases appear.

Key takeaways

• This attack worked because a trusted package publisher identity was compromised and used to deliver malicious releases under a legitimate name.
• The exposure mattered because the malicious axios versions combined a hidden dependency, a postinstall trigger, and self-deleting behaviour to evade simple inspection.
• Teams should govern publishing identities, install-time execution, and outbound network control as one supply chain defence model.

Key terms

• Trusted Publishing: Trusted publishing is a release method that ties package publication to a verified CI workflow, usually with short-lived identity tokens and provenance evidence. It reduces the value of stolen legacy credentials, but only if older publish paths are fully removed and not left alongside the new flow.
• Postinstall Script: A package lifecycle hook that runs automatically after installation. It is useful for legitimate setup tasks, but it also creates an execution path that can be abused to run malicious code as soon as a dependency is installed.
• Activation Trust Gap: The activation trust gap is the difference between trusting data because it is protected and governing it because it is being reused. It appears when organisations move data from backup or archival systems into AI pipelines without reapplying access, sensitivity, and consumer controls.
• Access Provenance: Access provenance is the record of how an identity was created, approved, used, and withdrawn. In NHI governance, it is the evidence trail that lets teams prove an account is legitimate, explainable, and still within its intended access boundary.

What's in the full analysis

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

• File-level diff analysis of the malicious dependency and the exact postinstall mechanics used to trigger execution
• Registry metadata evidence showing how the poisoned publish diverged from the normal trusted-publisher pattern
• Indicators of compromise, affected version guidance, and remediation steps for CI runners and developer machines
• Detection logic and workflow telemetry examples from Harden-Runner that show how the C2 callback was flagged

👉 StepSecurity's full post covers the attack chain, indicators of compromise, and remediation steps.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity teams apply lifecycle controls to the identities that now underpin software delivery.