Static secrets make npm supply-chain attacks far easier to scale

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Riptides's blog post: Trojanized npm packages turned install-time execution into secret hunting and account reuse across developer, CI, and cloud environments.

Why it matters: It matters because IAM and NHI programmes that still allow static tokens in repositories, build systems, or workloads give supply-chain malware a reusable foothold instead of a bounded compromise.

Context

Static secrets turn a package install into an identity event. When npm dependencies can read files, environment variables, or CI state, they can harvest credentials that were never meant to survive beyond a single workload or pipeline step.

The problem is not just secret exposure, but secret reusability. In a supply-chain attack, a valid token can become persistence, publication rights, cloud access, or workflow manipulation in minutes, which is why lifecycle control matters as much as detection.

This article uses the Shai-Halud campaign to show how secret scanning and token validation convert ordinary dependency execution into a practical intrusion path. That pattern is common wherever developers still store reusable credentials in build and deployment environments.

Key questions

Q: What breaks when npm install scripts can access long-lived credentials?

A: The install step stops being a safe execution boundary. A malicious preinstall script can read cached secrets, harvest tokens, and use legitimate identities to republish packages or access cloud systems. The failure is not only malware execution, but the presence of durable credentials in a context that assumes untrusted code cannot reach them.

Q: Why do valid tokens make supply-chain attacks worse than simple secret leaks?

A: A valid token is already an access mechanism, not just evidence of compromise. Once malware validates a live GitHub, npm, or AWS credential, it can immediately reuse that identity for publishing, workflow changes, or cloud actions, which turns exposure into operational abuse with very little friction.

Q: What are the signs that build systems are exposing reusable secrets?

A: Look for credentials present in CI variables, dependency install logs, local caches, developer dotfiles, and workflow files that can be read by untrusted package code. If package execution can reach those locations, the environment is already treating secrets as durable state instead of transient access.

Q: Should teams prioritise secret removal or token rotation first in npm pipelines?

A: Remove secrets first. Rotation helps only when a token is already constrained, but the article shows that install-time malware can discover and validate credentials before defenders notice. Eliminating static secrets from build paths reduces both immediate exposure and the chance that rotation becomes a cleanup exercise after compromise.

Technical breakdown

How install-time payloads turn packages into secret hunters

In this campaign, the malicious code executed during npm install, which means the attacker did not need a separate exploit chain once the package was trusted by the build or developer environment. The payload downloaded a secret-scanning binary, searched local files and environment variables, and then probed for tokens tied to GitHub, npm, and AWS. That sequence matters because install-time execution lands inside the same trust boundary as normal dependency handling, so any secrets exposed to the process become immediately collectible. Once the package can read the host state, the difference between software execution and credential theft disappears.

Practical implication: treat dependency install time as a credential exposure zone and keep reusable secrets out of that execution path.

Why credential validation makes stolen tokens immediately useful

The malware did not stop at discovery. It validated candidate credentials against provider endpoints such as GitHub APIs, npm whoami checks, and AWS-related calls, which filters out dead secrets and leaves only usable ones. That reduces attacker noise and speeds up abuse because each confirmed token can be used for publishing, workflow changes, or cloud access with little delay. This is a major difference from bulk secret scraping alone: validated secrets create immediate operational leverage. In identity terms, the problem is not discovery alone, but discovery plus live reusability inside a trusted execution context.

Practical implication: focus on shortening token lifetime and reducing reuse value, not just on detecting where secrets appear.

How valid tokens become persistence and lateral movement

Once the attacker has a working token, the campaign could write GitHub Actions workflows, republish packages, or use cloud credentials to move further across accounts and environments. That is the practical bridge from secret theft to persistence. The package no longer needs to remain on the host after install because the stolen identity can act elsewhere through normal platform APIs. This is why static credentials are dangerous in supply-chain settings: they are portable, durable, and often broad enough to outlive the original process that exposed them. The exploit path is simple because the token itself is the access mechanism.

Practical implication: scope tokens tightly enough that one stolen credential cannot become publishing rights, CI persistence, or cloud lateral movement.

Threat narrative

Attacker objective: The attacker wanted reusable access that could survive beyond a single package install and be leveraged for persistence, exfiltration, and lateral movement.

1. Entry began when trojanized npm packages executed a hidden payload during install time inside developer and CI environments.
2. Credential access followed as the payload scanned files, repositories, and environment variables for GitHub, npm, and AWS tokens, then validated which secrets were live.
3. Escalation and persistence followed when valid tokens were reused to publish changes, write GitHub Actions workflows, and extend access beyond the original host.
4. Impact included unauthorized package control, secret exfiltration, and the ability to move laterally into cloud and CI-adjacent systems using trusted credentials.

Breaches seen in the wild

• postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.
• 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

Static secret sprawl is the real supply-chain blast-radius problem: This campaign worked because reusable credentials were present where package code could reach them. The attacker did not need to defeat cryptography or break npm itself, only to find a credential that remained valid outside the workload that should have held it. The practitioner implication is clear: if a dependency install can read a usable secret, the blast radius is already too large.

Secret validation is what turns exposure into exploitation: Harvesting candidate strings is common, but checking them against live services is what makes the campaign operationally efficient. That changes the governance question from “was a secret exposed?” to “did an exposed secret remain valid long enough to be abused?” Teams need to evaluate token lifetimes, scope, and revocation speed as a single control plane rather than as separate hygiene tasks.

Supply-chain identity needs to be bound to workload context, not stored state: The article’s strongest lesson is that identity living on disk or in CI is fundamentally easier to steal than identity issued just for a specific workload. This is not a scanner problem, it is a lifecycle problem. Practitioners should treat static tokens as an architectural liability because they create a reusable access object where ephemeral access would create only a transient transaction.

Ephemeral credential trust debt is now a measurable programme risk: The longer a token survives across files, builds, and pipelines, the more value it accumulates for an attacker and the harder it becomes to reason about exposure. Riptides’ analysis shows that the supply chain can be compromised without a novel zero-day when trust is built around secrets that outlive their intended use. The implication is to review where your programme still depends on durable credentials rather than workload-bound identity.

Identity blast radius should be managed at issuance, not discovered after compromise: Supply-chain malware makes post-hoc investigation too late if the credential can already act as a publishing key, workflow writer, or cloud token. OWASP-NHI, NIST-CSF, and MITRE ATT&CK all map cleanly to this pattern because the central issue is credential access followed by lateral movement. The practitioner takeaway is to constrain access before secrets ever become broadly reusable.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — Key Challenges and Risks

What this signals

Secretless build paths are now a governance requirement: Supply-chain malware succeeds when build and dependency execution environments can reach durable credentials. The practical shift is from secret rotation as a hygiene task to secret removal as an architectural control, because reused tokens create the attack surface in the first place.

Static credential exposure is the control gap, not package trust alone: The campaign shows that signed or popular dependencies do not matter if the runtime still exposes valid access tokens. The governance question is whether your CI, developer, and workload identity model assumes secrets should survive long enough to be stolen.

For practitioners

• Eliminate long-lived credentials from build paths Remove static GitHub, npm, and cloud tokens from repositories, CI variables, images, and developer workstations so package installs cannot harvest reusable access.
• Bind non-human identity to workload context Issue credentials only for the workload that needs them and keep them out of disk-backed storage, build logs, and environment variables wherever possible.
• Reduce token reuse value Shorten TTLs, narrow scopes, and revoke tokens aggressively so a secret discovered during dependency execution cannot be reused for publishing or cloud access.
• Audit CI for secret exposure paths Review runners, caches, and workflow permissions for any path that lets untrusted package code read credentials, write workflows, or reach cloud APIs.

Key takeaways

• The campaign demonstrates that npm installs can become intrusion points when package code can reach static credentials in developer or CI environments.
• The evidence points to a familiar but undercontrolled failure mode: valid tokens remain usable long after they should have been ephemeral or workload-scoped.
• The most effective response is to remove reusable secrets from build paths and bind non-human identity to short-lived, tightly scoped access.

Key terms

• Static Secret: A secret, such as an API key or password, that does not change automatically over time. Static secrets require manual or scheduled rotation and represent a higher security risk than dynamic secrets or managed identities.
• Secretless Access: Secretless access is a pattern where workloads authenticate and receive access without relying on long-lived embedded credentials. It typically uses runtime identity verification, federation, and short-lived authorization decisions. The goal is to reduce exposure from hardcoded or reusable secrets while keeping machine-to-machine access functional.
• Malicious Package Supply Chain: A malicious package supply chain attack uses public registries or dependency workflows to deliver harmful code through software that developers expect to trust. The attacker relies on normal installation and update behaviour to reach build systems, secrets, or downstream environments before detection catches up.
• Token Validation: Token validation is the process of checking that a credential was issued by the right authority, has not expired, and is meant for the current request. For NHIs, validation must include issuer, audience, signature, scope, and context, otherwise a valid token can still be over-privileged.

Deepen your knowledge

NHI governance, secrets management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.