TL;DR: Two malicious Axios npm releases were published with a hidden dependency that executed at install time and could expose developer workstations, CI/CD secrets, and production credentials, according to CYCOGNITO. The incident shows that dependency trust must be treated as a runtime security problem, because postinstall execution can turn package installs into immediate compromise paths.
At a glance
What this is: CYCOGNITO's analysis of the Axios npm supply chain attack shows that install-time code execution can turn a routine package update into immediate machine compromise across developer and build environments.
Why it matters: IAM, PAM, and NHI teams need to treat build-time trust, credential exposure, and postinstall hooks as governance problems because compromise can occur before an application ever runs.
By the numbers:
- Axios is the most widely used HTTP client in the JavaScript ecosystem, with over 300 million weekly downloads.
Context
The security gap here is not just malicious code in a package, but the assumption that dependency installation is a safe, low-risk administrative action. When a package can execute code during install, the boundary between software supply chain integrity and endpoint compromise disappears, especially in developer workstations and CI/CD runners.
This is also an identity problem because the attacker is not only targeting code paths but the credentials and secrets available to the machine identity that performs the build. In environments where service accounts, tokens, and SSH keys are reachable during install, a supply chain event becomes an NHI governance failure as much as a software one.
The Axios case is typical of modern supply chain compromise patterns: trusted software is used as the delivery vehicle, and the blast radius is defined by where that software is installed rather than where it is executed.
Key questions
Q: What breaks when npm package installs are allowed to execute code before inspection?
A: The control point disappears. If install-time code can run before review, malware can harvest secrets, alter workflows, and propagate before defenders see a stable artifact. That makes preinstall hooks an execution surface, not a packaging detail. Teams should assume installation is a potential compromise event and enforce policy before code reaches that stage.
Q: Why do CI/CD runners and developer machines make supply chain attacks more damaging?
A: They often hold cloud credentials, repository tokens, deployment keys, and other high-value identities in one place. If those systems are allowed broad secrets access, a package compromise can move from code execution to repository control and environment access with very little extra effort.
Q: What do security teams get wrong about package lockfiles and registry trust?
A: Teams often assume that a clean registry entry or pinned version is enough to establish safety. In reality, hidden dependencies and lifecycle scripts can change what actually executes during installation, so version control alone does not prove behavioural integrity. Practitioners need to verify how the package behaves, not just what the lockfile names.
Q: What should teams do after a malicious npm package has run in CI/CD?
A: Contain the build environment, assume secrets on that system are exposed, and rebuild from a known-good baseline before restoring access. Then rotate npm tokens, cloud keys, SSH keys, and pipeline secrets that were reachable from the compromised host. The goal is to remove attacker persistence before any cleanup can be trusted.
Technical breakdown
Install-time execution turns package trust into code execution
A postinstall hook runs automatically when npm installs a package, which means the package manager itself becomes the execution path. In this case, the malicious dependency was hidden inside otherwise ordinary releases and executed before the developer or build system had a chance to inspect the final application. That matters because many controls still assume malicious behaviour happens at runtime, after deployment. Install-time execution collapses that assumption and creates a compromise path during dependency resolution, not during application use.
Practical implication: Treat dependency installation as an execution boundary and disable script execution in automated build paths where possible.
Why CI/CD runners and developer endpoints are high-value targets
Build machines usually have broader credential reach than application containers. They can access source repositories, cloud tokens, deployment credentials, package registry credentials, and environment files, all of which are useful for lateral movement or persistence. A machine identity used for CI/CD is often over-trusted because it is assumed to be temporary or isolated, but install-time malware can harvest whatever that identity can see at the moment of installation. That makes pipeline runners and developer endpoints more attractive than production hosts in many supply chain attacks.
Practical implication: Limit the secrets and privileges available to build identities and separate build-time access from deployment-time access.
Hidden dependencies and postinstall hooks undermine package integrity checks
A hidden dependency changes the trust boundary because the package manifest may not fully reflect what code will run during installation. If defenders only verify the published package name or version, they can miss behaviour triggered by lifecycle scripts, transitive packages, or tampered release artifacts. The attacker also removed traces after execution, which reduces the value of superficial inspection of node_modules after the fact. Supply chain integrity therefore depends on more than version pinning. It requires control over scripts, provenance, and the runtime permissions of the installer.
Practical implication: Add provenance checks, lockfile review, and script restrictions to the software acquisition process.
Threat narrative
Attacker objective: The attacker aimed to gain persistent access to development and build environments and harvest credentials that could be used to move into production systems.
- Entry occurred through stolen credentials from a lead Axios maintainer, which allowed malicious npm releases to be published under a trusted package name.
- Credential harvesting happened at install time when npm install triggered a postinstall hook that executed a hidden dependency and dropped a remote access trojan.
- Escalation followed as the trojan established outbound contact, removed traces, and exposed whatever source code, cloud credentials, SSH keys, and CI/CD secrets the machine could access.
- Impact was persistent remote access to affected developer and build systems, with the potential to reach production infrastructure through exposed deployment credentials.
Breaches seen in the wild
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
- Miasma and Hades Supply Chain Worms: Self-propagating supply chain worms Miasma and Hades compromise npm, PyPI, and Azure credential stores.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Install-time execution is now a supply chain control issue, not just a package hygiene issue. The Axios case shows that the decisive question is no longer whether a package is trusted at publish time, but whether it can execute code before the build pipeline has applied any guardrails. That shifts the control surface from software inventory to installer behaviour. Practitioners should treat postinstall scripts as an enforceable policy boundary, not an implementation detail.
Build identities need governance as machine identities, not as temporary convenience accounts. CI/CD runners and developer endpoints often carry high-value secrets precisely because teams assume they are short-lived and operationally isolated. This breach pattern shows that assumption is fragile when installer privileges can read tokens, keys, and environment files. The relevant problem is overexposed machine identity, and the practitioner conclusion is to narrow what build-time identities can see and do.
Hidden dependency execution creates a verification gap that traditional lockfile review cannot close on its own. A pinned version can still contain lifecycle scripts or transitive behaviour that changes the execution profile at install time. That is why provenance, script control, and artifact inspection need to work together. The field should name this problem install-time trust collapse, because the failure is the gap between package declaration and package behaviour.
This attack pattern validates a broader shift in software risk: the installer is part of the attack surface. Security teams increasingly manage software acquisition as a runtime concern because credentials, network access, and local permissions are all available before the application starts. That affects both application security and NHI governance, since the identities used to build software often have more access than the software itself. Practitioners should align build controls with that reality rather than with package-manager assumptions.
Supply chain compromise now routinely targets the secrets plane, not only the code plane. The practical value of a malicious dependency is the access it can extract from the machine that installs it. Once source, tokens, and deployment credentials are within reach, the incident becomes a credential governance problem with code delivery as the entry mechanism. Teams need to organise response around exposed secrets and machine access, not just around package removal.
From our research library:
- 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.
- Read next: Secrets Management Buyer's Guide
What this signals
Install-time trust collapse: the real failure mode is the gap between a package's published identity and the code it can execute before the build pipeline applies any guardrails. Once that gap exists, dependency management becomes a runtime governance problem for both software and machine identities.
The immediate programme implication is to treat build systems as credential-rich environments and to reduce what postinstall hooks can see. That means narrowing secret exposure, separating build and deploy privileges, and making package installation an enforceable control point rather than an administrative convenience.
For practitioners
- Disable lifecycle scripts in automated builds Use npm ci --ignore-scripts in CI/CD and review whether any build step genuinely requires postinstall execution before enabling it.
- Rebuild exposed systems from known-good baselines Treat any endpoint or runner that installed the malicious releases as compromised and rebuild it rather than trying to clean the working tree in place.
- Rotate all install-time-accessible secrets Rotate cloud keys, CI/CD secrets, npm tokens, SSH keys, and any other credentials the build identity could access during the exposure window.
- Audit lockfiles and pipeline logs for affected versions Search package-lock files and build logs for references to the affected Axios versions and use that evidence to identify which systems need containment.
Key takeaways
- The Axios npm attack shows that dependency installs can become execution events, which turns package trust into an endpoint and build-system risk.
- The compromise matters because build identities often hold cloud keys, CI/CD tokens, SSH keys, and source access that attackers can reuse for broader intrusion.
- The most effective limiting controls are to block lifecycle scripts in automation, rebuild affected systems from trusted baselines, and rotate every credential exposed during installation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The attack exposed secrets reachable from install-time execution paths on affected machines. |
| NHI-03 — Vulnerable Third-Party NHI | A compromised maintainer account and third-party package turned trusted supply chain access into malware delivery. | |
| Recommendation — Scan build logs and package workflows for leaked secrets and revoke any credentials exposed during installation. Review third-party package trust relationships and remove elevated access paths from external maintainers where possible. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The trojan was designed to harvest credentials and enable broader access from compromised build systems. |
| Recommendation — Map exposed installer activity to credential access and lateral movement detection in your security monitoring. | ||
| CIS Controls v8 | CIS-5 — Account Management | Compromised maintainer and build identities show why account governance is central to this supply chain attack. |
| Recommendation — Enforce account lifecycle reviews for maintainers, CI identities, and any privileged automation accounts. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The incident exploited excessive access available to the installation identity and the secrets it could reach. |
| Recommendation — Limit installer entitlements so build identities cannot access more credentials than the build requires. | ||
Key terms
- Install-Time Execution: Install-time execution is code that runs while dependencies are being installed rather than when an application is launched. In supply chain attacks, this matters because the install phase often has access to the richest secrets in developer and CI environments, making it a high-value privilege boundary.
- Preinstall Hook: A preinstall hook is package code that runs before an application installs or starts. In supply-chain attacks, it becomes a hidden execution point that can steal secrets, alter environments, or drop further payloads before normal controls see the package's behaviour.
- Build identity: The set of credentials, tokens, keys, and permissions used by CI/CD systems, runners, and developer tooling. Build identity is often overlooked, yet it can expose secrets, alter repositories, and propagate compromise into downstream software if not tightly scoped and monitored.
- Software Supply Chain Trust Boundary: The software supply chain trust boundary is the point where an organization decides which software components, build systems, dependencies, and delivery steps it will trust. It defines where verification must occur. Technically, it includes source, build, signing, packaging, distribution, and update paths, plus the identities and controls that govern each stage.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is suitable for practitioners who need to connect machine identity governance to build-time trust and secrets exposure.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org