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

At a glance

What this is: This is an analysis of a Red Hat npm supply chain compromise that used install-time code execution to steal credentials and secrets at speed.

Why it matters: It matters to IAM and NHI practitioners because package trust can collapse into credential theft, making workload identity, secrets exposure, and runtime enforcement part of the same control problem.

By the numbers:

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

👉 Read AccuKnox's analysis of the Red Hat npm supply chain attack and runtime defense

Context

Supply chain attacks against build tooling are now identity attacks as much as software integrity attacks. When a trusted package can execute code during install, the immediate target is often not the application itself but the credentials, tokens, and cloud secrets that the build environment already exposes. In this case, the primary security gap is the assumption that package trust and execution trust are the same thing.

The Red Hat npm compromise shows why this matters for NHI governance. A poisoned package can read service credentials, republish itself, and exfiltrate secrets before human operators or traditional alerting loops can react. That makes non-human identity exposure, runtime file access, and egress control part of the same operational control surface.

Key questions

Q: What breaks when malicious npm packages execute during CI/CD installs?

A: The main failure is that package installation becomes code execution inside a trusted build context. That lets attacker-controlled scripts read memory, steal secrets, and potentially publish more malicious artifacts before defenders notice. The control that breaks is the assumption that dependency installation is operationally harmless. Treat install-time execution as a governed security boundary, not a routine developer convenience.

Q: Why do build runners create such high-risk NHI exposure?

A: Build runners often contain the credentials that let automation act across source control, cloud platforms, and container systems. When those credentials are stored in predictable paths or environment variables, a malicious dependency can harvest them quickly and reuse them outside their intended scope.

Q: What signs suggest a supply chain attack is moving faster than detection tools?

A: Look for exfiltration that completes during package install, unusual repository creation from build identities, and token reuse from accounts that should only publish software. When the attack chain finishes in seconds, alerting after the event is evidence collection, not prevention.

Q: How should security teams respond to poisoned package publishing rights?

A: Treat package publishing as privileged access and apply tighter lifecycle control to the tokens and automation identities that can publish. Review scope ownership, rotate high-risk tokens, and reduce the number of identities that can republish trusted software into public registries.

Technical breakdown

How npm lifecycle hooks become an execution path

npm lifecycle hooks such as preinstall and postinstall let package authors run arbitrary code before the application code loads. That is convenient for legitimate setup, but it also means a poisoned dependency can execute with the build user's permissions during routine installation. In this attack, the malware did not need a user click or an application exploit. It only needed the package manager to trust the package metadata enough to run the hook.

Practical implication: treat install-time execution as hostile by default and restrict which packages are allowed to execute hooks in build pipelines.

Why credential harvesting from build environments is so effective

Build and CI environments routinely hold SSH keys, npm tokens, GitHub tokens, cloud credentials, and Kubernetes secrets in standard locations such as environment variables and configuration files. The malware searched those paths and copied the contents before committing them to attacker-controlled repositories. This is not simple data theft. It is non-human identity abuse, because the attacker is harvesting the credentials that let workloads, pipelines, and repositories act on behalf of the organisation.

Practical implication: reduce standing access in pipelines and separate build-time secrets from broad-purpose credentials wherever possible.

Why detection lags behind kernel-level enforcement

Detect-and-respond tooling works after behaviour is observed, scored, and escalated. That works for slower intrusions, but not for malware that reads secrets, exfiltrates them, and republishes itself inside seconds. Kernel-level controls using eBPF and Linux Security Modules evaluate policy at syscall time, so an unauthorised file read or process launch can be denied before the action completes. The difference is timing, not just visibility.

Practical implication: use inline denial for sensitive paths and outbound destinations on high-trust build and runner workloads.

Threat narrative

Attacker objective: The attacker wanted to harvest reusable credentials, expand package compromise through self-replication, and turn trusted build accounts into a distribution mechanism for further theft.

1. Entry occurred when a poisoned npm package was installed through an ordinary build or CI workflow, allowing the preinstall hook to run with the build user's privileges.
2. Credential access followed as the payload read SSH keys, tokens, cloud secrets, and Kubernetes credentials from standard files and environment variables.
3. Impact came when the stolen data was committed to attacker-controlled GitHub repositories and used to republish more poisoned packages under the victim's account.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.

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

NHI Mgmt Group analysis

Install-time code execution is now a governance failure, not just a developer convenience risk. The attack worked because npm lifecycle hooks let untrusted code run before the application even starts. That means package trust, execution trust, and secret trust cannot be managed as separate problems. Practitioners should treat install hooks as an execution boundary in policy design, not as a harmless setup feature.

Non-human identity compromise is the real payload in many supply chain attacks. The worm did not need to steal customer passwords or exploit a human login flow. It harvested the credentials that let pipelines, cloud accounts, and repository automation act at machine speed. This is exactly where OWASP NHI guidance and the OWASP Non-Human Identity Top 10 are relevant: the exposed secret, not the package name, is what enables blast radius.

Runtime denial changes the economics of speed-based malware. The attack chain finished in seconds, which makes post-event detection structurally late. Inline enforcement at syscall time creates a different control model because the denial happens before the read, spawn, or egress completes. For identity security teams, the lesson is that secrets governance must extend into workload execution, not stop at rotation policy.

Self-replicating supply chain malware should be treated as a persistence mechanism for stolen credentials. Once a compromised package can republish itself through stolen tokens, the attack moves from one-off theft to distributed reuse of the victim's own publishing rights. That widens the governance problem from access control to lifecycle control across package publishing, token scope, and repository trust. Practitioners should view package publishing rights as privileged access.

Runtime security and NHI governance now overlap in build environments. The control gap is not only whether secrets are rotated. It is whether the environment can prevent an installed package from reading those secrets at all. That intersection between workload identity, secrets exposure, and execution policy is where identity governance is expanding in practice.

From our research:

• The non-human identity governance gap is already measurable: only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
• A separate finding shows 88.5% of organisations acknowledge their non-human IAM practices lag behind or merely match their human identity and access management efforts, according to the same report.
• For a broader control lens, see Top 10 NHI Issues for the recurring failure patterns that let machine credentials become easy targets.

What this signals

Credential theft in build systems is becoming a workload identity problem. As more software supply chain attacks target tokens, keys, and repository privileges, IAM teams need a control model that treats CI runners and package publishers as governed identities. The next step is to align secrets handling with workload identity policy, not leave it inside developer tooling. For broader control context, the OWASP Non-Human Identity Top 10 is the right companion reference.

Runtime denial is now a practical part of identity defence. If malware can steal credentials during install in under a minute, post-event detection is too slow to be the only answer. Build environments that handle secrets need prevention at execution time, plus tighter scope controls for tokens that can publish or republish software. That changes how security teams should think about trust in automation pipelines.

The named concept here is install-time credential capture: malware uses routine package execution to read secrets before any application logic runs. That pattern is especially dangerous because the attacker does not need a novel exploit chain, only access to the normal build path. Practitioners should prepare for more attacks that turn dependency installs into non-human identity theft events.

For practitioners

• Restrict install-time execution in CI pipelines Block or tightly whitelist npm lifecycle hooks such as preinstall and postinstall on build runners that handle privileged credentials. Assume package installation can execute arbitrary code and enforce policy accordingly.
• Separate build secrets from broad-purpose credentials Move SSH keys, cloud tokens, and repository tokens out of shared runtime locations and reduce what any single runner can read. Treat credential scope in build systems as a non-human identity design problem, not just a secrets storage problem.
• Enforce inline denial on sensitive file paths Use kernel-level policy to deny unauthorised reads of environment variables, secret files, and token stores before the action returns. This is most important on runners that handle high-value packages or publish to registries.
• Map package publishing rights as privileged access Inventory who and what can republish packages, rotate the associated tokens, and apply stronger controls to scope owners and CI identities that can push to public registries. Publishing rights should be reviewed like any other privileged access path.
• Correlate SBOMs with compromised package windows Use software bill of materials data to identify which builds consumed affected versions, then trace downstream deployments and exposed workloads. That gives teams a concrete way to scope exposure after a dependency compromise.

Key takeaways

• This attack shows that a poisoned dependency can become a credential-harvesting system, not just a software integrity issue.
• The evidence points to speed as the decisive factor, with the worm stealing and republishing secrets inside the same installation window.
• Teams that run privileged builds need runtime denial, tighter token scope, and lifecycle control for publishing identities.

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.
• Build Runner Identity: A build runner identity is the account, role, or token used by CI or developer automation while packages are installed and software is assembled. It often has broader reach than a normal user session, which makes it a valuable target when malicious code executes during dependency installation.
• Credential Harvesting: Credential harvesting is the collection of secrets, tokens, keys, or certificates from a compromised workload. In container environments, it often targets file paths, environment variables, service account tokens, and metadata services because those locations frequently hold reusable identity material.
• Inline Runtime Enforcement: Inline runtime enforcement blocks unsafe actions before they complete by making policy decisions at execution time. Unlike detection-only tooling, it can deny file access, process spawn, or network exfiltration in the kernel path, which matters when attacks complete in seconds.

What's in the full article

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

• Kernel-level enforcement examples showing how eBPF and Linux Security Modules block the attack path
• The runtime policy matrix for denying unauthorised process execution, file access, and egress
• How the xBOM and SBOM workflow helps identify affected builds after a dependency compromise
• The live attack flow shown in the console, including how the denial happens before the payload completes

👉 The full AccuKnox analysis covers the attack chain, the install-time payload, and the runtime controls that stop it.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It gives practitioners a practical way to connect identity controls to build pipelines, automation, and privileged access.