Malicious axios packages expose the runtime blind spot in supply chain security

At a glance

What this is: This is Oligo Security's analysis of malicious axios packages published through compromised credentials and the runtime compromise that followed.

Why it matters: It matters because teams managing NHI, CI/CD, and developer access need controls that detect what executed, not just what was declared in a manifest.

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.

👉 Read Oligo Security's analysis of malicious axios packages published through compromised credentials

Context

Malicious package publication is a supply chain identity problem as much as it is a malware problem. In this case, the attacker used compromised maintainer credentials to publish tainted axios versions, which means the trust boundary failed before the code ever reached an application runtime.

For NHI and DevSecOps teams, the key issue is that package managers routinely execute code during install. That makes secrets in CI, developer workstations, and build containers reachable through a non-human identity path that traditional manifest-based reviews do not observe.

Key questions

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. Freeze affected builds, rotate any secrets present on impacted systems, and check whether install-time scripts were allowed to run. If the package manager executed code during install, the runtime environment, not just the manifest, needs investigation.

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. A package can arrive through a trusted channel, run install-time code, and access local secrets before scanners or approvals see anything unusual. That makes runtime behaviour the meaningful control point.

Q: What do security teams get wrong about dependency scanning?

A: They often assume a clean manifest means a clean environment. In reality, package managers can resolve transitive code dynamically and execute scripts during installation. A scan can confirm what should have been installed, but it cannot prove what actually ran or what secrets the code reached.

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.

Technical breakdown

Compromised maintainer credentials as the entry point

The attack did not rely on a vulnerability in axios. It began with stolen maintainer credentials, which let the attacker publish malicious versions through the legitimate npm distribution channel. That matters because the package ecosystem treats publishing authority as trusted by default, so control failures at the identity layer can translate directly into software distribution abuse. The dangerous part is not only access to an account, but access to the release path that downstream systems automatically trust.

Practical implication: enforce publisher identity protection, maintainer MFA, and release-path monitoring on every critical package account.

Postinstall execution turns dependency install into code execution

The malicious payload rode inside a dependency that executed automatically during npm install. In Node.js environments, postinstall scripts can run without a developer making an explicit security decision, which turns dependency resolution into runtime execution. That is why package scanning is insufficient on its own: the declared package tree is not the same as the code path that actually runs. If the install step is allowed to execute scripts, a dependency can become an active foothold before the application even starts.

Practical implication: disable automatic script execution where possible and inspect install-time behaviour in CI and build environments.

Runtime persistence and secret exposure in developer and CI environments

Once the RAT was dropped, it connected to command and control, fetched second-stage payloads, and cleaned up traces. That sequence gave the attacker a foothold on the host and access to whatever secrets were present in memory, environment variables, or local credential stores. In practical terms, this is where supply chain compromise becomes identity compromise: the attacker no longer needs to break a second perimeter if the compromised workload already holds usable tokens, SSH keys, or cloud credentials.

Practical implication: treat affected build hosts and developer machines as credential-exposure events, not just package incidents.

Threat narrative

Attacker objective: The attacker aimed to gain persistent foothold and harvest reusable secrets from developer and CI environments for lateral movement and follow-on compromise.

1. Entry occurred when the attacker used compromised maintainer credentials to publish malicious axios versions through npm.
2. Credential access followed when npm install executed a postinstall script from the malicious dependency and dropped a cross-platform RAT.
3. Impact occurred when the RAT connected to command and control and exposed SSH keys, API tokens, cloud credentials, and environment variables on the host.

Breaches seen in the wild

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

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

NHI Mgmt Group analysis

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.

Secret exposure is the real blast radius of dependency compromise: Once malicious code runs on a developer machine or in CI, the immediate prize is not the package itself but the credentials sitting beside it. SSH keys, API tokens, cloud access credentials, and environment variables are all reachable through the same install-time foothold. Practitioners should stop classifying these events as isolated package incidents and start treating them as credential compromise with software-supply-chain origin.

Runtime context closes the gap that manifests cannot see: A manifest tells you what was intended, but not what the package manager resolved, executed, or chained in at install time. That gap is where attackers operate, especially when transitive dependencies and install hooks are involved. The practical conclusion is that detection must move to runtime evidence if teams want to know whether a package actually executed malicious code.

Identity governance for build systems is still too static: The controls used to govern CI/CD and developer tooling were designed for known accounts and predictable behaviour, not for malicious packages that execute during normal onboarding or build flows. This is a standing privilege problem disguised as a software issue. Practitioners need to rethink where build identities can reach, because the attack surface is now defined by what those identities can execute as well as what they can read.

Secret sprawl and supply chain trust are converging into one failure mode: The same environment that installs packages also stores the credentials that attackers want after execution starts. That makes the compromise path shorter and the response window smaller than most teams assume. For security programmes, this is the point where secrets management, dependency control, and runtime detection become one governance problem, not three separate ones.

From our research:

• 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.
• For the governance angle, see 52 NHI Breaches Analysis for patterns that repeat when identity trust is treated as static.

What this signals

Runtime visibility is becoming the deciding factor in supply chain governance: teams that only review manifests will continue to miss install-time execution and postinstall payloads. The programme shift is toward observing what the build system actually did, not what the dependency tree claimed it would do.

Secret sprawl now intersects with package trust at the point of execution: when a build host already contains credentials, one malicious dependency can turn software installation into a credential harvesting event. That makes secrets governance and dependency control the same operational conversation.

If your organisation is prioritising NHI controls, this incident is a reminder that build identities need the same scrutiny as production workloads. A package install path that can reach reusable tokens is a privileged path, and privileged paths should be visible, constrained, and continuously monitored.

For practitioners

• 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. This removes the easiest execution path for malicious postinstall payloads and forces deliberate inspection before code can run.
• 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. Preserve process trees and dependency evidence before cleanup so forensics can establish the full exposure path.
• 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. Provenance checks should cover both declared dependencies and the install-time code path.
• Shift detection from manifest review to runtime inspection Add application runtime telemetry that records executed functions, spawned processes, and outbound connections from build and application environments. That gives security teams evidence of malicious behaviour even when the package tree looks normal at review time.

Key takeaways

• The axios incident shows that supply chain compromise becomes identity compromise once install-time code reaches secrets on developer or CI systems.
• The scale of the risk is not only package distribution but the rapid exposure of SSH keys, API tokens, cloud credentials, and environment variables on affected hosts.
• The control that changes outcomes is runtime inspection paired with hardened install defaults, because manifest review alone cannot prove what executed.

Key terms

• Install-Time Execution: Code that runs as part of dependency installation rather than at application startup. In Node.js ecosystems, this can be triggered by package scripts such as postinstall hooks, turning a routine install into an execution path that can reach local secrets and spawn external connections.
• Runtime Inspection: Observation of what software actually executes on a host or in a pipeline, rather than what a manifest or lock file says should be present. It reveals process trees, outbound traffic, and code paths, which is essential when malicious behaviour is delivered through trusted packages.
• Supply Chain Identity Abuse: The misuse of legitimate publishing or distribution credentials to introduce malicious code into trusted software channels. This is an identity problem because the attacker exploits trust in a maintainer or release account, then leverages that trust to reach downstream environments.
• Secret Exposure Event: A security incident in which credentials, tokens, keys, or certificates become reachable by an attacker after compromise of a host, pipeline, or build environment. The exposure may be brief, but any reusable secret should be assumed compromised and rotated immediately.

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.

👉 Oligo Security's full post covers the attack chain, indicators of compromise, and remediation steps for affected builds.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.