npm account freezes show registry controls for package takeover

At a glance

What this is: npm has added a 72-hour read-only freeze for high-impact accounts after sensitive changes, aiming to interrupt account takeover and malicious publishing paths.

Why it matters: This matters because package registries are identity systems as much as software distribution systems, and IAM teams need to account for the security impact of compromised maintainer sessions, recovery paths, and publish controls.

By the numbers:

• axios does about 100 million downloads a week.

👉 Read Aikido's analysis of npm's 72-hour account freeze for high-impact packages

Context

Package registries are an identity and trust problem as much as they are a software supply chain problem. When a maintainer account is taken over, the attacker does not need to break the build pipeline if they can change recovery details, seize a live session, and publish directly to a high-trust package stream.

The npm cooldown is best understood as a compensating control for identity compromise, not a complete supply chain defense. It reduces the chance that an attacker can immediately convert account control into malicious publishing, and it gives defenders a short window to detect and contain suspicious changes before they become broadly distributed.

Key questions

Q: What breaks when package publishing still depends on persistent maintainer privilege?

A: Persistent maintainer privilege lets an attacker convert a single session compromise into immediate release authority. If email recovery, publish tokens, and approval flow are all still active, the attacker can bypass CI and ship malicious versions before defenders can react. The breakage is not only technical. It is governance failure around who can still publish after trust has changed.

Q: Why do package registries need identity controls as well as malware scanning?

A: Malware scanning helps after code exists, but identity controls stop an attacker from publishing the code in the first place. Package ecosystems are trust chains built on maintainer accounts, recovery settings, and workflow credentials. If those identities are compromised, the registry may distribute malicious packages before any scan or review can intervene.

Q: How do security teams know whether their release identity model is working?

A: Look for whether sensitive account changes trigger containment, whether long-lived tokens have been removed, and whether critical releases require a separate approval path. If compromised credentials or recovery changes can still lead directly to publication, the model is not working. Effective governance reduces both the speed and the reach of a takeover.

Q: Who is accountable when a stolen maintainer account pushes malicious packages?

A: Accountability sits with both the project maintainers and the organisation operating the publishing identity. Teams should define who owns package release rights, who can revoke them, and how quickly compromised publisher access can be removed. That governance belongs in access review and offboarding processes.

Technical breakdown

Why account takeover beats pipeline controls

Many registry attacks bypass CI/CD entirely because the attacker operates inside a legitimate maintainer session. If the attacker can change the email address, use a recovery code, or take over the device, they can publish from the human path rather than the automated path. That makes the registry itself the last meaningful enforcement point. A read-only freeze creates a temporary break in the chain, giving security teams time to verify whether the change was legitimate.

Practical implication: treat registry account changes as identity events that need alerting, review, and rapid containment.

How OIDC publishing and staged releases change the risk model

Trusted publishing replaces long-lived tokens with short-lived OIDC credentials bound to a CI workflow, which removes a major secret theft path. Staged publishing adds human approval before release, which reduces the chance that automation alone can push a compromised release. But neither control solves live-session abuse if the attacker already controls the maintainer account. That is why publish security now has to combine credential hygiene, approval flows, and account recovery protections.

Practical implication: map publish authority across tokens, workflows, and human approvals so one compromise does not bypass the others.

Why registry cooldowns matter for non-human identity governance

Package publishing sessions, CI credentials, and registry tokens are all non-human identities in practice because they act on behalf of a workflow or maintainer. If those identities are not tightly scoped and quickly revoked, takeover becomes a governance problem rather than a malware problem. The interesting shift is that npm is enforcing a temporary lock on the account, not just trying to detect malicious code after publication. That changes the control boundary from detection to interruption.

Practical implication: inventory maintainer, workflow, and token identities with the same discipline used for privileged service accounts.

Threat narrative

Attacker objective: The attacker wants to turn maintainer identity control into trusted package distribution so malicious code is published at scale.

1. Entry occurs when attackers use social engineering to compromise a maintainer’s machine or live account session rather than attacking the registry directly.
2. Credential access and abuse follow when the attacker changes account recovery details or uses an active session to seize publish authority.
3. Impact occurs when malicious versions are published from the trusted maintainer path, bypassing CI controls and reaching downstream consumers.

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

Registry account control is now an identity security problem, not just an AppSec problem. npm’s freeze model acknowledges that the most dangerous point in package compromise is often account recovery and publish authority, not code scanning after the fact. That matters because a registry can only defend what it can see, and maintainer identity changes are one of the few visible signals in a largely opaque attack chain. The practitioner conclusion is clear: package registries need identity-aware controls, not only malware detection.

Standing publish authority is the failure mode this update is trying to interrupt. The article shows how attackers can route around CI by abusing a live maintainer session, which exposes the assumption that secure pipelines alone protect releases. When a human or workflow identity can still publish immediately after recovery detail changes, the control gap is not code quality but account lifecycle governance. Practitioners should treat this as a zero-standing-privilege problem for release authority.

Ephemeral publish trust is becoming a better model than persistent maintainer privilege. OIDC-backed trusted publishing and staged approvals both reduce the value of stolen tokens, but the registry still needs a mechanism to pause suspicious identity transitions. That is the governance shift here: constrain the blast radius of a compromised identity before the attacker can complete a release. The conclusion for identity teams is to align registry controls with lifecycle events such as email changes, recovery code use, and approval handoffs.

Package ecosystems increasingly depend on non-human identity governance. CI credentials, registry tokens, and release automation all act as workload identities, and they need the same inventory, rotation, and offboarding discipline as privileged service accounts. A package maintainer compromise is therefore not an isolated developer incident, but a signal that identity sprawl has reached the software supply chain. The practitioner conclusion is to govern publishing identities as critical infrastructure.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• Next: Read NHI Lifecycle Management Guide for the control patterns that reduce the window between identity compromise and release abuse.

What this signals

Registry cooldowns are a signal that software supply chain security is converging with identity lifecycle governance. Teams that still separate package publishing from privileged identity management will miss the real control gap, which is not malware detection but post-compromise containment. The practical response is to treat maintainer accounts, recovery paths, and CI publishers as governed identities with explicit ownership and offboarding.

Blast radius now depends on how fast you can interrupt an identity transition. A suspicious email change is no longer just an account admin event, because in a package ecosystem it can be the prelude to malicious distribution. Programmes that align registry events with access review, token revocation, and incident escalation will be better placed to limit downstream exposure.

Lifecycle discipline matters because publishing identities are operational identities. When release authority lives too long, the attacker inherits the trust of the maintainer. That is the same pattern seen in other NHI environments, where persistent credentials create a window for abuse that outlasts the original compromise.

For practitioners

• Freeze high-impact publish accounts on identity changes Alert and temporarily restrict publish, token, visibility, and membership actions when maintainer email or recovery settings change, so reviewers can verify the change before malicious releases land.
• Move high-trust packages to OIDC-backed publishing Replace long-lived publishing tokens with short-lived OIDC credentials scoped to CI workflows, and remove any tokens that can still be stolen from developer machines or build hosts.
• Require staged approval for critical releases Use a human approval step for packages with broad dependency impact, and make the approver distinct from the automated publishing path whenever possible.
• Monitor registry recovery paths as security events Treat unexpected email changes, recovery code use, and authentication resets as incident triggers, not account admin tasks, because they often mark the start of takeover.
• Inventory publishing identities alongside service accounts Catalog maintainers, CI publishers, tokens, and recovery contacts together so offboarding, rotation, and ownership checks cover every path to release authority.

Key takeaways

• npm’s freeze model shows that identity changes can be the earliest reliable signal of package takeover.
• Maintainer sessions, recovery paths, and publish tokens now function like high-risk non-human identities that need lifecycle governance.
• The strongest defensive pattern is to combine short-lived publishing trust with automatic containment when account control changes.

Key terms

• High-impact account: A high-impact account is a registry or platform identity whose compromise can affect many downstream users, packages, or services. In package ecosystems, these accounts often control publication, ownership, or recovery paths, so abuse can quickly turn into supply chain exposure.
• Trusted Publishing: Trusted publishing is a release method that ties package publication to a verified CI workflow, usually with short-lived identity tokens and provenance evidence. It reduces the value of stolen legacy credentials, but only if older publish paths are fully removed and not left alongside the new flow.
• Staged publishing: Staged publishing is a release control where a package is prepared in one state and only made public after a human approval step. It helps prevent automated or fully compromised workflows from pushing unreviewed releases directly to consumers.
• Registry cooldown: A registry cooldown is a temporary restriction placed on an account after risky identity changes, such as email swaps or recovery-code use. It creates a pause that can interrupt takeover attempts and give defenders a window to verify whether the change was legitimate.

What's in the full article

Aikido's full blog post covers the operational detail this post intentionally leaves for the source:

• A step-by-step breakdown of the axios compromise chain and why the registry only saw one part of it.
• The exact behaviour of npm's 72-hour read-only state for high-impact accounts after sensitive changes.
• Practical guidance on configuring stage-only trusted publishing and disabling tokens for CI releases.
• A short comparison of registry cooldowns, staged publishing, and trusted publishing as layered controls.

👉 Aikido's full post covers the axios compromise, staged publishing, and the new registry freeze in more operational detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It helps security and identity practitioners align operational controls with the realities of persistent access and release authority.