Axios npm compromise shows runtime secret exposure in supply chains

At a glance

What this is: This analysis shows that a compromised axios package can harvest secrets at runtime without breaking application behaviour.

Why it matters: It matters because IAM, PAM, and NHI controls often assume credentials are protected at rest, while supply chain attacks increasingly target them during execution.

By the numbers:

• 17 minutes.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Xygeni’s analysis of the axios npm compromise and runtime secret exposure

Context

Axios-style supply chain compromises are a secrets governance problem as much as they are a software integrity problem. A dependency that executes inside build pipelines or applications inherits the runtime context of the host, which means tokens, headers, and environment variables can be exposed without any visible functional failure. In practice, this collapses the assumption that static review alone is enough to protect secrets.

For identity teams, the issue sits at the boundary between application security and NHI governance. API keys, service tokens, and cloud credentials are non-human identities in practice, even when they are embedded into developer workflows rather than explicitly managed as identities. That makes lifecycle control, revocation speed, and runtime visibility central to the response. The attack pattern is now familiar rather than exceptional.

This pattern is typical of modern dependency abuse: the package is not the target, the credentials it can reach are.

Key questions

Q: How should security teams respond when a dependency may have accessed secrets at runtime?

A: Contain first by identifying which credentials were exposed, then revoke or rotate the secrets that are still valid. Review pipeline logs, runtime telemetry, and outbound traffic for evidence of reuse. The goal is to cut off legitimate authentication paths that attackers can reuse, not just to remove the malicious package.

Q: Why do trusted dependencies create such a large supply chain risk for credentialed applications?

A: Because they inherit the application’s execution context. If a package can run where headers, tokens, or environment variables are present, it can reach credentials without exploiting the application itself. That makes the issue one of runtime trust and secret governance, not only code provenance.

Q: What do organisations get wrong about machine secrets in CI/CD pipelines?

A: The most common mistake is treating secrets as deployment convenience rather than identity risk. When keys, tokens, and service accounts are embedded in pipelines, ownership becomes blurred and revocation becomes slower than development. That creates hidden trust paths that are hard to audit and easy to reuse across systems.

Q: Should organisations prioritise secret rotation or dependency review after a package compromise?

A: Both matter, but rotation of still-valid secrets usually reduces immediate risk faster. Dependency review helps you find the entry path and any other affected packages, while rotation and revocation close the attacker’s access window. If a credential is live, it is the urgent containment problem.

Technical breakdown

How a compromised dependency reaches secrets at runtime

A malicious package does not need to exploit memory corruption or break authentication to cause damage. It only needs to execute in a trusted runtime where application code already has access to sensitive data. In the axios pattern, request interceptors run before outbound HTTP calls, which gives the payload a convenient place to inspect headers, environment variables, and internal request context. That is why runtime trust matters more than package reputation alone. The supply chain risk is created when execution and secret access overlap.

Practical implication: treat dependency execution as a secret exposure event, not just a code inclusion event.

Why static scanning misses secret theft in build and app layers

Static analysis is useful for spotting known malicious code, but it cannot reliably model what a dependency will do once loaded inside a live pipeline or service. A package may look harmless in a repository scan while still accessing process.env, outbound requests, or internal authentication flows at runtime. That gap is why exploitability must be evaluated behaviorally. In a supply chain attack, the dangerous capability is often hidden in the interaction between code, execution context, and data exposure, not in the package contents alone.

Practical implication: add runtime telemetry and secret-access monitoring to complement repository scanning.

Why valid credentials are the real prize in supply chain compromise

Attackers increasingly prefer valid credentials because they bypass many defensive layers and blend into normal operations. Once a compromised dependency captures an API token or service key, the attacker does not need to escalate through a traditional exploit chain. They can authenticate as the application, move across services, and exfiltrate data with legitimate traffic patterns. This is why secrets lifecycle governance is now inseparable from software supply chain security. If a secret can be used after exposure, it is an active identity problem, not only a code security problem.

Practical implication: prioritise rapid verification and revocation of exposed secrets over broad forensic cleanup.

Threat narrative

Attacker objective: The attacker’s objective is to steal valid application and pipeline credentials that enable stealthy access to internal systems and data.

1. Entry occurs when a trusted npm dependency is compromised and distributed through ordinary update channels into developer machines, CI/CD pipelines, and application builds.
2. Credential access follows when the malicious package executes at runtime and inspects headers, tokens, environment variables, and internal HTTP traffic.
3. Impact occurs when captured secrets are exfiltrated and reused to access downstream services, while the application continues operating normally.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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

NHI Mgmt Group analysis

Runtime secret exposure is the core failure mode here. The axios compromise is not mainly about malicious code in the abstract, but about a trusted library executing in a context where secrets are already present. That turns ordinary application behaviour into a credential harvesting opportunity. For identity and security teams, the lesson is that valid credentials must be governed as live assets, not treated as passive configuration.

Supply chain risk is now an NHI governance problem as much as a software problem. API keys, service tokens, and cloud credentials are non-human identities, even when they are embedded inside pipelines and runtime environments. When those credentials are reachable by dependencies, the control gap is lifecycle ownership, not just code review. NHI governance must therefore include provenance, access scope, and rapid revocation for secrets exposed through build and runtime paths.

Secret sprawl creates a wider blast radius than most teams admit. The more environments, managers, and pipeline stages that hold credentials, the more places a compromised dependency can reach. That is why fragmented secrets management weakens detection and response. The named concept here is runtime secret exposure window: the period between secret access by a trusted component and revocation by the owner. Practitioners should shorten that window aggressively.

Runtime telemetry matters more than signature-led detection. Traditional malware indicators are often absent in package compromise events because the malicious behaviour is embedded inside normal execution. The better control is observation of secret access, outbound connections, and unusual dependency updates across CI/CD and production. Teams that rely only on static controls will miss the moment when trusted software begins acting as a data exfiltration path.

This pattern accelerates the move from dependency trust to identity governance. Once a dependency can access credentials, the security question shifts from 'is the package known good' to 'what identities can this code reach, and how quickly can they be revoked'. That is the boundary where software supply chain security and IAM converge. Practitioners should manage secrets as identity-bearing assets with explicit ownership and expiry.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• The spread of 6 distinct secrets manager instances shows why fragmented control makes runtime exposure harder to govern, according to The State of Secrets in AppSec.

What this signals

Runtime secret exposure window: the period between a dependency or service touching a secret and the moment that secret is revoked. Teams should treat this as a measurable control objective, not a theoretical risk, and use secrets management research to benchmark response speed.

The governance signal is clear: dependency security, secrets management, and identity lifecycle control are converging. Where a package can observe live credentials, the real question becomes whether the organisation can detect that access, prove who owns the secret, and remove it before reuse. That is the operating model shift practitioners should prepare for.

For security programmes that already track NIST SP 800-53 Rev 5 Security and Privacy Controls, the useful next step is to align secret handling to access and audit controls rather than treating credentials as static configuration.

For practitioners

• Enforce runtime secret access monitoring Track when dependencies, build jobs, and services read process.env, authentication headers, or mounted secret material so that unexpected access is visible during execution, not only after exfiltration.
• Shorten the secret exposure window Map each API key, service token, and CI/CD credential to an owner, expiry, and revocation path, then rotate or revoke anything that cannot be validated quickly after exposure.
• Separate build credentials from application runtime credentials Use distinct identities for packaging, deployment, and application execution so a compromised dependency cannot reuse the same secret across pipeline stages and production services.

Key takeaways

• The compromise shows that trusted dependencies become identity threats when they can observe live secrets at runtime.
• The most important evidence is not code maliciousness but credential reach, because valid tokens and API keys can be reused immediately.
• Teams should reduce the secret exposure window by tying runtime monitoring, rotation, and revocation to the same response workflow.

Key terms

• Runtime Secret Visibility: Runtime secret visibility is the ability to observe when and where secrets are accessed while systems are actively running. It matters because static inventories alone do not show whether a tool, workflow, or workload is reading credentials in memory, files, or logs.
• Dependency Supply Chain: The dependency supply chain is the path packages follow from publication to installation in code, CI, or developer environments. It includes registries, mirrors, package managers, and endpoint configuration, all of which can become trust failures if they are not governed end to end.
• Secret lifecycle governance: Secret lifecycle governance is the set of controls that manage creation, distribution, rotation, expiry, and revocation for credentials. It treats secrets as living access artefacts rather than static text. That approach is essential when the same credential may travel through code, email, and automation.
• Metadata Trust Boundary: A metadata trust boundary is the line between tool content that can be safely consumed and tool content that must be validated before use. For agentic systems, descriptions, examples, and schemas are security-relevant inputs because they can influence decisions and trigger actions with real-world impact.

What's in the full article

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

• Exact indicators of compromise, including package names, domains, IPs, and host artefacts for hunt teams.
• Runtime interception example showing how a malicious dependency can extract headers and secrets before requests leave the application.
• Guidance on scanning pipelines and artefacts for exposed credentials before starting revocation and recovery.
• Response workflow detail for verifying which secrets are still active versus already invalid.

👉 Xygeni’s full article covers the attack flow, indicators of compromise, and remediation steps in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in practical terms. It helps security practitioners connect identity lifecycle control to real-world exposure paths across modern delivery pipelines.