Runtime defense for poisoned npm packages: what stops AI-era theft

At a glance

What this is: This is an analysis of a poisoned npm supply chain attack in which install-time code execution turned trusted packages into credential theft tools.

Why it matters: It matters because build and runtime controls have to stop malicious package behaviour before secrets are read, not after exfiltration has already completed.

By the numbers:

• 32 @redhat-cloud-services npm packages were poisoned in the attack.
• The packages carried close to 10 million collective downloads.
• The worm published across a 72-second window.
• OX Security found stolen credentials in over 210 GitHub repositories.

Context

The security gap here is not simply malware in a package registry. It is the assumption that trusted software can execute during install without crossing a policy boundary, even when that execution can read secrets, contact external services, and modify repositories.

In npm, lifecycle hooks such as preinstall run automatically before application code loads, which means a poisoned dependency can act with the privileges of the build user. For identity teams, this is also a non-human identity problem because tokens, SSH keys, cloud credentials, and GitHub credentials become the stolen assets that translate package execution into real access.

This attack pattern is typical of modern supply chain compromise: the abuse begins at install time, but the consequences spill into CI/CD runners, source control, cloud access, and workload identities.

Key questions

Q: What fails first when a poisoned npm package runs during install?

A: The first failure is trust in the install boundary. npm lifecycle hooks can execute before application code loads, so a compromised package can read secrets, contact external systems, and alter the host while still appearing to be a routine dependency install. That is why execution control has to start at package install, not after the process is already active.

Q: Why do compromised CI/CD credentials make supply chain attacks much worse?

A: CI/CD credentials often sit at the centre of publish, build, and deployment workflows, so one stolen token can reach many repositories and environments. If those credentials are not scoped, rotated, and monitored like privileged identities, attackers can use them to publish malicious packages, access secrets, and spread laterally across trusted automation.

Q: How do security teams know if runtime protection is actually working?

A: Look for evidence that suspicious behaviour is detected fast enough to contain it before the session or workload expands the blast radius. Effective runtime protection produces actionable alerts, ties them to containment steps, and shows that abnormal access can be limited during active execution, not only reviewed afterward.

Q: How can organisations know whether package-related secret exposure is actually under control?

A: Look for three signals: fewer long-lived credentials in developer paths, narrower privilege on the secrets that remain, and visible enforcement for package provenance in pipelines. If build and import events can still touch high-value secrets, control is not yet working. You should be able to map every sensitive secret to a short-lived, explicitly owned use case.

Technical breakdown

How npm install hooks become execution points

npm lifecycle hooks such as preinstall allow package authors to run code automatically during installation. That makes the install step an execution boundary, not a passive file copy. If the package has been poisoned, the attacker code runs before developers inspect or import the library, and it inherits the privileges of the build process. In CI/CD environments that privilege often includes access to source control, registries, cloud credentials, and deployment secrets, which turns a routine dependency fetch into a control-plane event.

Practical implication: treat package installation as an execution path and constrain it with default-deny policy and signed dependency controls.

Why secret harvesting succeeds so quickly

Once the malicious hook is running, the objective is credential collection, not persistence. The payload can read SSH keys, npm tokens, GitHub tokens, environment variables, and cloud config files from the predictable locations build tooling uses. Because those reads happen locally and immediately, traditional detect-and-respond tools often see only the aftermath. The attacker gains value the moment a secret is copied into memory, encrypted, and staged for exfiltration. In this pattern, the speed of compromise is the defence problem, not the sophistication of the malware alone.

Practical implication: reduce the number and lifetime of secrets present on build systems, especially where non-human identities authenticate to downstream services.

Why runtime policy beats after-the-fact telemetry

Inline runtime defence changes the enforcement point from observation to authorisation. With eBPF and Linux Security Modules, a control can deny a process launch, a file read, or a network connection before the syscall completes. That is materially different from logging or alerting, which always occurs after the action. In this attack class, the difference determines whether a stolen token leaves the host or is blocked at the kernel boundary. Runtime enforcement therefore protects both the system and the identity material exposed during install.

Practical implication: place policy at the syscall layer for build runners and Kubernetes nodes so credential reads and unauthorized egress never complete.

Threat narrative

Attacker objective: The attacker wanted to steal usable credentials, republish backdoored packages, and expand access through the victim’s own identities and repositories.

1. Entry occurred when a poisoned npm package executed through a preinstall hook during routine install on a build or CI runner.
2. Credential access followed as the payload read SSH keys, npm tokens, GitHub tokens, and cloud secrets from local files and environment variables.
3. Exfiltration and propagation came next as stolen data was committed to attacker-controlled repositories and used to republish compromised packages.
4. Impact was the exposure of credentials and the creation of a self-spreading supply chain compromise that could extend into cloud and source control access.

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).
• Code Formatting Tools Credential Leaks: Widely used code formatting tools cause massive credential and secrets leaks in enterprise environments.

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 package execution is now an identity compromise problem, not just a software integrity problem. The article shows that a poisoned dependency can steal secrets the moment it is installed, which means the compromise boundary sits inside the build process itself. That shifts governance from package trust to execution control, because the real asset is not the package but the credentials it can reach. Practitioners should treat package install as an identity-sensitive event.

Credential theft from CI/CD runners is a non-human identity failure mode. The stolen items in this attack were not only files but machine credentials, cloud tokens, and repository tokens that represent delegated access. Once those non-human identities are present on a runner, the attacker does not need interactive access to the system. Security teams need to govern where those identities exist, not just whether they are rotated later.

Runtime defense is the right control layer when compromise happens faster than detection. Detection assumes there is time to observe behaviour, score it, and respond. This attack compressed the whole sequence into seconds, which makes post-event telemetry insufficient as a primary barrier. The decisive control is inline denial at execution, file access, and egress, because that is where the malicious action still depends on authorization.

Secret sprawl across build infrastructure creates a wider blast radius than the package itself. The article’s details about SSH keys, npm tokens, GitHub tokens, and cloud secrets show how one poisoned install can expose multiple trust domains at once. That is a classic governance gap: secrets are distributed for convenience, but their lifecycle is not bounded tightly enough to the task. Practitioners should regard build hosts as high-value identity containers.

Shai-Hulud style self-replication turns third-party package trust into a supply chain propagation problem. Once the attacker can reuse stolen npm tokens to republish backdoored versions, one compromised maintainer account becomes a distribution channel for the next victim. That pattern reinforces why secret leakage, package provenance, and runtime policy belong in the same governance conversation. The practitioner conclusion is to assume trusted dependencies can become active attack infrastructure.

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.
• The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
• Read next: Ultimate Guide to NHIs — Static vs Dynamic Secrets

What this signals

Credential-read prevention is now a build-system control objective. When a malicious package can steal SSH keys, cloud tokens, and repository credentials during install, the governing question becomes where the read is denied, not how quickly the theft is detected. Build environments need identity-aware execution boundaries because the identities most at risk are non-human and ephemeral.

Secret sprawl is the blast-radius multiplier in supply chain compromise. The more credential types a runner can reach, the more downstream systems a single poisoned install can touch. Teams should map which machine identities live on which runners and remove any secret that is not strictly required for that workload.

Runtime denial and secret minimisation are now linked controls, not separate hygiene tasks. Inline policy reduces the chance that malicious code can execute, while tighter secret placement reduces what it can steal if it does. In practice, that means treating CI/CD runners as privileged identity zones that deserve the same scrutiny as production workloads.

For practitioners

• Lock down package install execution Block unknown lifecycle scripts on build runners and CI nodes so preinstall and postinstall hooks cannot execute by default.
• Reduce secrets on ephemeral build systems Keep SSH keys, npm tokens, GitHub tokens, and cloud credentials off runners unless a job absolutely requires them, and scope each secret to the shortest possible task.
• Enforce kernel-level file and process policy Use inline controls to deny unauthorized reads of secret paths and unapproved process execution before the syscall returns.
• Restrict egress from build environments Allow only approved destinations from CI/CD workloads so encrypted secret uploads and attacker-controlled repository writes are blocked.
• Pair SBOM review with admission control Block deployment of workloads that pull flagged package versions and trace affected builds back to the dependency version that introduced the compromise.

Key takeaways

• A poisoned npm package can turn a normal install into a credential theft event because lifecycle hooks execute before application code runs.
• The scale of the Red Hat npm incident mattered because 32 packages, close to 10 million downloads, and a 72-second publish burst created a large and fast attack surface.
• The control lesson is clear: block malicious execution, file reads, and outbound exfiltration inline, because detection alone is always behind the theft.

Key terms

• Lifecycle Hook: A lifecycle hook is code that runs automatically at defined stages of package installation or build processing, such as preinstall or postinstall. These hooks are powerful because they can execute before deeper inspection or controls are applied, making them a common abuse path in supply chain attacks.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.
• 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.

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 govern machine credentials, workload identities, and lifecycle controls across modern environments.