npm token hardening shows why standing secrets fail in CI pipelines

At a glance

What this is: This is an analysis of npm’s move away from bypass-2FA access tokens and toward OIDC publishing, with the key finding that standing credentials remain the core CI risk.

Why it matters: It matters because IAM, PAM, and NHI teams need to treat pipeline tokens as privileged identities, not convenience artifacts, or one exposed secret can still cascade across build, cloud, and registry access.

By the numbers:

• The compromised packages represented roughly 16 million weekly downloads.
• The change follows the Mini Shai-Hulud attack, in which a single compromised npm token was used to push 639 malicious package versions across 323 packages in 22 minutes.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.

👉 Read Akeyless's analysis of npm token hardening and secretless publishing

Context

npm’s move is best understood as a control response to standing credential abuse in software delivery. A long-lived token inside a CI pipeline is not just an authentication mechanism. It is a portable identity with enough authority to publish packages, manage accounts, and reach adjacent systems if the runner is compromised.

For identity teams, the important issue is not npm alone. Any workflow that still depends on reusable secrets is inheriting the same failure mode: a credential exists, can be copied, and can outlive the run that created the business need for it. That is a machine identity problem first, and a tooling problem second.

Key questions

Q: What breaks when CI pipelines still rely on standing npm tokens?

A: Standing npm tokens turn a release workflow into a reusable identity artifact. If the token is stolen, the attacker can reuse it outside the intended run, publish malicious packages, and often pivot into adjacent secrets on the same runner. The break is not only authentication. It is the collapse of containment around machine identity.

Q: Why do reusable credentials increase supply chain risk in build systems?

A: Reusable credentials remain valid long enough to be copied, cached, logged, or exfiltrated. That gives attackers a window to act after the original workflow has finished. In build systems, that window is especially dangerous because the same host frequently holds cloud, registry, and signing credentials together.

Q: What do security teams get wrong about token rotation in CI pipelines?

A: They often treat rotation as equivalent to removal. Rotation shortens exposure, but it still leaves a valid secret that can be stolen during its lifetime. If the workflow can operate without a standing secret, secretless publishing is the stronger control because it removes the object attackers want to steal.

Q: Who is accountable when a compromised publish token is used to tamper with packages?

A: Accountability sits with the organisation that allowed a privileged credential to persist beyond the task it served. For IAM and PAM teams, that means the governance question is who owned the token lifecycle, who approved exceptions, and who accepted the blast radius created by standing access.

Technical breakdown

Why bypass-2FA tokens were a high-value identity surface

A bypass-2FA token is a standing credential that carries registry authority without requiring an interactive verification step for every sensitive action. In CI, that makes it efficient for automation and equally efficient for attackers once it is stolen. The core weakness is persistence: if the token lives in a secret store, environment variable, or runner configuration, it can be copied and reused outside the original trust boundary. The attack surface widens further when the same pipeline host also holds cloud keys, SSH material, or signing certificates. Practical implication: treat publish tokens as privileged identities with blast radius, not as low-risk build secrets.

Practical implication: classify every reusable publish token as a privileged machine identity and constrain where it can be presented, copied, and audited.

How OIDC trusted publishing removes the standing secret

OIDC trusted publishing replaces a durable token with a short-lived assertion about a specific workflow run. The CI provider proves the run is real and current, and the registry exchanges that proof for a credential scoped to that single operation. Once the run ends, the credential expires and there is no reusable secret sitting in a vault or repository variable. This is the security value: the attacker no longer steals a durable artifact and instead has to compromise the workflow while it is active, which materially compresses the attack window. Practical implication: secretless publishing changes the question from secret protection to workflow trust and runtime provenance.

Practical implication: prefer ephemeral, run-scoped publishing credentials where the platform supports them, and map every exception as temporary technical debt.

Why co-located secrets make CI compromise systemic

Mini Shai-Hulud showed the common pattern in CI compromise: the first token is only the entry point. Once malware lands on the runner, it can enumerate other secrets in memory, on disk, or in the environment and chain them into cloud, source control, and vault access. That is why secret sprawl in pipelines is so dangerous. The credential that started the incident is often not the credential that caused the largest impact. Practical implication: pipeline security must be designed around containment of adjacent secrets, not only the first credential exposed.

Practical implication: assume compromise of one pipeline secret exposes the rest unless credentials are isolated by task, environment, and runtime boundary.

Threat narrative

Attacker objective: The attacker aims to seed malicious package versions at scale and then pivot into adjacent credentials for broader supply chain access.

1. entry via a compromised npm token that allowed malicious package publishing into a high-trust ecosystem.
2. escalation through package maintainer and registry authority, enabling fast propagation across dozens of packages before detection.
3. impact through downstream supply chain infection and harvesting of additional machine credentials from the same build environment.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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

NHI Mgmt Group analysis

Standing publish tokens are now a supply chain liability, not a convenience layer. The article’s core lesson is that registry authority accumulated too much durable privilege for too long. Once a token can manage accounts, organizations, and packages, compromise is no longer limited to publishing abuse. Practitioners should read this as a reminder that every reusable pipeline secret expands blast radius, not just access.

Credential persistence is the failure mode, not token scope alone. Scope reduction helps, but Mini Shai-Hulud showed that a single valid token was enough to trigger package abuse and then harvest adjacent secrets. That means the real control gap is the survival of a credential after the task that justified it has ended. The implication is that lifecycle governance for machine identities must prioritize removal over refinement.

Secretless publishing is the new baseline for high-trust software release paths. OIDC trusted publishing shifts the trust decision from stored secret possession to runtime proof of workflow execution. This is not only a registry change. It is a signal that modern release governance is moving toward Zero Standing Privilege for build and publish operations. Practitioners should reassess every place where a durable credential still stands in for runtime identity.

Machine identity governance must now span registry, CI, cloud, and vault surfaces together. The attack path described here does not respect product boundaries. A package token can be the first compromise, but the operational impact comes from whatever else the runner can reach. The discipline now is to govern the full credential constellation around software delivery, not a single publish step.

Ephemeral credential trust debt: Teams that keep delaying secretless workflows are accumulating trust debt in every pipeline run. The older the exception window, the larger the set of systems that can be chained once one secret is exposed. Practitioners should treat that debt as a measurable governance issue, not a future optimisation.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• From our research: 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
• For a broader control view, see the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for lifecycle, rotation, and offboarding patterns that reduce credential persistence.

What this signals

Standing secret removal is now the programme-level differentiator. As build systems become more automated, teams should expect pressure to replace reusable publish credentials with task-scoped identities and short-lived assertions. The control question is no longer whether a token is well protected, but whether it should exist at all. For a control baseline, align release governance to OWASP Non-Human Identity Top 10 and the privilege model in NIST Cybersecurity Framework 2.0.

With 64% of valid leaked secrets still exploitable in our research, the operational burden shifts from discovery to revocation and containment. Teams that cannot revoke or replace pipeline secrets quickly should assume the compromise window remains open long after detection.

Pipeline blast-radius control: The practical programme issue is not a single npm token but the entire credential set co-located on the runner. If the build environment still holds cloud keys, SSH material, and registry access together, one incident can become multi-system compromise.

For practitioners

• Inventory every standing publish credential Map npm tokens, CI variables, runner secrets, and registry API keys to the workflows and teams that can still use them. Flag any credential that survives beyond one release run or can be reused outside the original build context.
• Move publish paths to short-lived OIDC trust Adopt OIDC trusted publishing wherever supported and document every remaining exception with an expiry date. The goal is to eliminate durable publish tokens from routine releases and reserve them only for temporary transition cases.
• Separate build secrets from adjacent machine identities Do not leave cloud keys, SSH material, vault credentials, and package tokens co-located on the same runner. Use task-scoped isolation so compromise of one credential does not expose the rest of the pipeline.
• Treat registry administration as privileged access Require live verification, session recording, and explicit approval for maintainer changes, token re-issue, and organisation membership changes. These actions deserve PAM-level controls because they change who can publish and govern the package surface.

Key takeaways

• The article shows that registry hardening is really a machine identity governance problem, because durable tokens carry more authority than teams often assume.
• The Mini Shai-Hulud campaign demonstrates how quickly one compromised credential can scale into package tampering and adjacent secret harvesting.
• Secretless publishing and short-lived workflow identity are the controls that most directly reduce the blast radius of CI compromise.

Key terms

• Standing Credential: A standing credential is any secret that remains usable until it is manually rotated or revoked. In NHI governance, it creates durable access that can be stolen, replayed, or propagated from trusted tooling unless runtime boundaries and expiry are built in.
• OIDC Trusted Publishing: OIDC trusted publishing uses a short-lived federated assertion from the CI system to prove a workflow is current and authorised. The registry exchanges that proof for ephemeral publish access, which removes the need to store a durable package token.
• Zero Standing Privilege: A control model in which an identity does not keep persistent access unless it is actively needed. For NHIs, this means credentials and permissions are issued for a narrow task and then removed. It reduces the time window and reuse value of stolen access.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

What's in the full article

Akeyless's full article covers the operational detail this post intentionally leaves for the source:

• The step-by-step transition guidance from bypass-2FA npm tokens to OIDC trusted publishing in CI environments
• The operational controls Akeyless describes for vaulting, IP restriction, audit logging, and governed token re-issue during the transition window
• The internal registry and private repository access model for eliminating standing publish credentials across pipeline stages
• The administrator access controls for maintainer changes, token management, and session recording in npm administration

👉 Akeyless's full post covers the Mini Shai-Hulud attack chain, transition window, and pipeline controls in detail

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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 or identity security programme, it is worth exploring.