npm Just Killed the Skeleton Key: What It Means for Every Other Credential You Own

Quick answer: Starting July 31, 2026, GitHub blocked npm access tokens configured to bypass two-factor authentication from managing accounts, organizations, or packages. Those operations now require a live 2FA prompt. Bypass-2FA tokens still work for direct publishing until January 2027, when npm shifts publishing to OIDC trusted publishing: a short-lived credential scoped to one workflow run, with no standing token to steal. 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.

Introduction

For years, one stolen npm token was enough to take over a maintainer’s account completely: publish malicious packages, mint new tokens, add backdoor maintainers, and rewrite an organization’s access controls, all without a single human verification step.

That era is ending. Effective July 31, 2026, GitHub restricted npm granular access tokens configured to bypass two-factor authentication from performing account, organization, and package management operations. Those operations now require an interactive 2FA challenge that no script, stolen token, or remote attacker can satisfy. And by January 2027, bypass-2FA tokens will lose direct publish access entirely, pushing the ecosystem toward OIDC trusted publishing and staged, human-approved releases.

This is not an incremental hardening patch. It is a public admission, from the registry that serves the world’s most-downloaded software, that a persistent credential is a liability that cannot be managed away. It can only be removed.

At Akeyless, we have been making that argument for years. npm just proved it at ecosystem scale.

The Attack That Forced the Issue

The change did not come out of nowhere. In May 2026, the TeamPCP cybercrime group executed the Mini Shai-Hulud campaign against the @antv ecosystem, pushing 639 malicious versions across 323 packages in a 22-minute automated burst. The compromised packages represented roughly 16 million weekly downloads. Across all waves, researchers tracked more than 1,000 compromised versions across 500-plus packages spanning npm, PyPI, and Composer.

Here is the detail every security leader should sit with: the malware did not stop at npm tokens. According to StepSecurity’s analysis, it harvested GitHub tokens, AWS keys, Google Cloud and Azure tokens, SSH private keys, Kubernetes service accounts, secrets pulled from HashiCorp Vault, and the contents of local password vaults.

The npm token was the entry point. The standing credentials sitting next to it were the payday.

Why “Harder to Steal” Was Never Going to Work

Every long-lived credential, no matter how carefully stored, scoped, or rotated, shares one fatal property: it exists. And anything that exists somewhere can be exfiltrated from somewhere.

npm’s answer, OIDC trusted publishing, attacks that property directly. The CI provider presents a cryptographically signed assertion that a specific workflow in a specific repository is running right now. The registry exchanges it for a short-lived publish credential scoped to that single run. When the run ends, the credential is gone. There is nothing durable to steal, because nothing durable was ever created.

If that architecture sounds familiar, it should. It is the same model we describe as the path to secretless machine authentication, and it maps to four generations of maturity:

1. Static secrets embedded in code, config files, and CI variables. This is where the Mini Shai-Hulud victims were harvested.
2. Auto-rotation, which shrinks the exposure window but leaves the credential standing.
3. Dynamic, Just-in-Time identities created on demand and destroyed after use: Zero Standing Privileges.
4. Secretless authentication through OIDC, OAuth, and SPIFFE, where workload identity replaces the stored credential entirely.

npm just mandated generation four for publishing, with a hard deadline. The question for every engineering organization is simple: why would you accept generation one for everything else in the pipeline?

Takeaways

• Any credential that exists can be exfiltrated. Mini Shai-Hulud didn’t need a novel technique. It needed one static npm token to reach GitHub, AWS, Google Cloud, Azure, SSH, Kubernetes, and HashiCorp Vault credentials sitting on the same runner.
• Rotation manages exposure. It doesn’t remove risk. A token that rotates every 30 days is still valid for the 30 days between rotations, and it can still be copied, cached, or logged during that window.
• Administrative actions carry more blast radius than publish actions. Minting a token, adding a maintainer, or changing organization membership went unguarded for years while publish access got most of the security attention. npm’s fix targeted the bigger risk first.
• Blast radius grows with co-located secrets. The attack spread past npm the moment the malware found unrelated credentials sitting in the same CI environment. The npm token was the way in. It wasn’t the reason the damage was so large.
• Short-lived, scoped credentials remove the target rather than defend it. A credential tied to one workflow run and destroyed when that run ends can’t be stolen after the fact, no matter how well it was guarded while it existed.
• A fix at the registry doesn’t fix the pipeline. npm secured one credential type on its own timeline. Every other secret in that same CI environment, cloud keys, database passwords, signing certificates, is exactly as exposed as it was on July 30.

What We Recommend: Secure Every Surface, Not Just the Publish Step

The npm changes create four distinct credential surfaces, and each demands a different control. This is how the Akeyless Identity Security Platform addresses them.

1. Publishing to npmjs.com: adopt OIDC trusted publishing, and make the rest of the pipeline match it

For supported CI platforms, npm’s native OIDC trusted publishing is the right mechanism, and we recommend it without reservation. But securing the publish token while leaving static AWS keys, database passwords, and signing credentials in the same runner misses the lesson of Mini Shai-Hulud entirely.

Akeyless extends the same secretless pattern to everything else the pipeline touches. The workflow authenticates to Akeyless using its CI provider’s OIDC token, with no stored Akeyless credential, eliminating the “secret zero” problem. It then receives every other credential it needs as a Just-in-Time dynamic secret with a TTL measured in minutes. A compromised runner has nothing durable to hand over.

2. The transition window: vault, bind, and watch the tokens you still hold

OIDC trusted publishing does not yet support self-hosted runners, and direct publish via bypass-2FA tokens survives until January 2027. Teams in that window still hold long-lived npm tokens, and those tokens deserve better than a CI variable store.

The Akeyless treatment: centralize the token in the platform, protected by our patented Akeyless DFC™ (Distributed Fragments Cryptography), which ensures no whole key ever exists anywhere, not even at Akeyless. Deliver it to pipelines Just-in-Time through native CI integrations, so it never lands in a .env file or repository secret. Restrict the token itself to your gateway or runner egress IPs, so an exfiltrated copy is useless from attacker infrastructure. And alert on every anomalous read through item-level audit logs and Event Center notifications to Slack, ServiceNow, or your SIEM.

One point of candor: npm’s changes deliberately broke automated token rotation, since minting a token now requires an interactive 2FA challenge. Any vendor promising hands-free npm token rotation is describing the exact skeleton-key pattern npm just eliminated. The right model is governed manual re-issue, driven by expiry notifications, with the new value propagating instantly to every consuming pipeline.

3. Account administration: treat it as privileged access, because npm now does

Token management, maintainer changes, and organization membership are now interactive, 2FA-gated human operations. In other words, npm converted registry administration into a privileged access management problem.

Akeyless Modern PAM handles it as one. Secure Remote Access brokers the administrator’s session to npmjs.com through an isolated browser with full session recording, producing audit evidence of exactly who changed what and when. Akeyless Password Manager governs the maintainer credential itself with role-based and attribute-based policies, such as corporate-VPN-only access during business hours. The second factor stays where it belongs: on the human’s enrolled device, never wired into automation.

4. Private registries: full Zero Standing Privileges, today

Most enterprises front npmjs.com with a private registry such as JFrog Artifactory, and there the constraints disappear. Akeyless dynamic secrets mint ephemeral, scoped Artifactory access tokens per pipeline run, expiring automatically minutes later. For the internal half of your npm supply chain, standing publish credentials can be eliminated entirely, right now.

Go Secretless With Akeyless

npm’s hardening campaign is a structural correction, not a patch, and the logic generalizes beyond one credential type. Credentials that persist will eventually be stolen, and credentials that carry standing authority will eventually be abused. The registry fixed this for one credential type, on its own timeline, under the pressure of a 500-package supply chain attack.

You do not have to wait for every other system you run to reach the same conclusion the hard way. The Akeyless Identity Security Platform brings secretless authentication, Just-in-Time dynamic credentials, and Zero Standing Privileges to every machine identity in your environment, from CI pipelines to databases to cloud consoles, with the recorded, policy-governed human access npm now requires.

The skeleton keys are being melted down. Make sure npm’s is not the only one. Ready to see what secretless machine identity looks like across your entire pipeline? Request a demo or explore the Akeyless documentation to get started.

Frequently Asked Questions