Notifications
Clear all
Topic starter
11/08/2026 3:15 pm
TL;DR: GitHub’s July 31, 2026 change forces live 2FA for npm account and package management, then moves publishing toward OIDC trusted publishing in January 2027 after the Mini Shai-Hulud campaign used one compromised npm token to push 639 malicious versions across 323 packages in 22 minutes, according to Akeyless. Standing credentials remain the real problem: once a token exists, attackers can steal, reuse, and chain it into wider machine identity compromise.
NHIMG editorial — based on content published by Akeyless: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
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.
Questions worth separating out
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.
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.
Q: What do security teams get wrong about token rotation in CI pipelines?
A: They often treat rotation as equivalent to removal.
Practitioner guidance
- 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.
- Move publish paths to short-lived OIDC trust Adopt OIDC trusted publishing wherever supported and document every remaining exception with an expiry date.
- 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.
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
👉 Read Akeyless's analysis of npm token hardening and secretless publishing →
npm token hardening: what it means for CI and machine identity?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
11/08/2026 3:28 pm
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.
A few things that frame the scale:
- 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.
- 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.
A question worth separating out:
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.
👉 Read our full editorial: npm token hardening shows why standing secrets fail in CI pipelines
