What should teams do after a malicious npm package has run in CI/CD?

Why This Matters for Security Teams

A malicious npm package that executes inside CI/CD should be treated as a supply chain compromise, not a routine dependency issue. The build runner often holds npm tokens, cloud credentials, artifact signing material, and deployment secrets, so the attacker’s first objective is usually persistence and reuse. NIST guidance on control hardening and credential protection in NIST SP 800-53 Rev 5 Security and Privacy Controls maps directly to this scenario.

NHIMG has documented how supply chain intrusions turn exposed build systems into credential harvesters, including the Shai Hulud npm malware campaign and the Nx Package Attack. GitGuardian’s State of Secrets Sprawl 2026 reports that 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners, which shows why this environment deserves immediate containment. In practice, many security teams discover the blast radius only after attacker-controlled automation has already touched secrets, caches, and downstream deploy jobs.

How It Works in Practice

The response starts with containment. Pause the pipeline, isolate the runner, and assume every secret reachable from that host is compromised. That includes npm tokens, cloud provider keys, SSH keys, signing certificates, artifact registry credentials, and any injected environment variables. If the runner was ephemeral, preserve logs and images before teardown so forensic teams can reconstruct what executed and what the package accessed.

Then rebuild from a known-good baseline. Recreate the runner image, refresh dependencies from trusted sources, and restore pipeline access only after the environment has been reimaged and validated. For CI/CD, this is not just a host recovery exercise. It is a credential recovery exercise. The malicious package may have exfiltrated secrets, written backdoors into caches, poisoned artifacts, or modified workflow files. A clean rebuild without secret rotation leaves attacker persistence intact.

Practitioners should prioritize short-lived credentials and workload identity over long-lived static secrets. Where possible, use OIDC-based federation, per-job tokens, and tightly scoped access tied to the build identity rather than a shared account. That approach aligns with the operational direction in CI/CD pipeline exploitation case study and the broader Guide to the Secret Sprawl Challenge. Pair that with NIST SP 800-53 Rev 5 Security and Privacy Controls for rotation, logging, and least privilege.

• Rotate every secret the compromised runner could read, not just the one package used.
• Invalidate cached credentials, registry sessions, and workflow-issued tokens.
• Re-sign artifacts only after provenance is re-established.
• Review downstream jobs for lateral movement into deploy, release, or infrastructure stages.

These controls tend to break down in long-lived self-hosted runners with shared caches and broad environment injection because the exact secret exposure boundary becomes difficult to prove.

Common Variations and Edge Cases

Tighter containment often increases pipeline downtime, requiring organisations to balance recovery speed against the risk of reintroducing a poisoned environment. The right response varies with runner architecture, but the default assumption should remain conservative until evidence says otherwise.

When the malicious package ran in a fully ephemeral runner with no persistent disk, cleanup is still not automatic. Logs, artifact stores, dependency caches, and external API sessions may already be compromised. When the package ran in a shared build pool, the risk expands further because adjacent jobs may inherit the same cached state or network trust. Best practice is evolving, but there is no universal standard for how much of a shared CI/CD estate must be rebuilt versus selectively remediated.

If the build also touched package publishing or release automation, treat public distribution channels as exposed and verify whether attackers could have pushed a tampered artifact. If secret scanning or detection fired late, assume exfiltration occurred before alerting. For teams studying attack patterns, NHIMG’s Reviewdog GitHub Action supply chain attack illustrates how quickly a trusted workflow can become a secret collector. The practical lesson is simple: if the runner could reach it, rotate it, and if the runner could persist to it, rebuild it.

Related resources from NHI Mgmt Group

• How should teams reduce risk from malicious npm package installs?
• How should security teams stop malicious CI/CD workflow commits from executing?
• What should teams do after a malicious repository or package is discovered?
• How should teams respond when a malicious npm package can steal build secrets?