npm now holds publishing for 72 hours after any recovery-code sign-in

npm extended a 72-hour publishing pause to every account that signs in with a recovery code, GitHub said in a changelog post on September 9. The hold used to apply only to high-impact accounts, meaning maintainers of widely used packages. It now covers everyone with an npm login.

What the hold does

For 72 hours after a successful recovery-code sign-in, npm pauses publishing and other security-sensitive writes, including creating access tokens. The account owner can still sign in, browse packages, and install them; the block applies to writes that could publish code to everyone. The hold expires automatically, so there is no need to ask npm support to remove it.

Why the scope changed

Recovery codes are the fallback path when a maintainer loses their normal second factor. They exist so an account is not locked out forever. The same property that makes them useful in a recovery makes them the weakest point in an account takeover, because an attacker who obtains them can log in without using the phone or hardware key that backs the account. Slowing publishing for three days after any recovery-code login is a way of giving time to a real owner to notice a stolen sign-in before a malicious release goes public.

GitHub frames the change as "further slowing account-takeover attempts and reducing the risk of malicious publishing from a compromised recovery code". That is the pattern npm has suffered all summer: an attacker gets into a maintainer account, publishes a malicious version, and teams that depend on the package download it before anyone knows the login was stolen. A three-day publishing pause on a login that a real owner would use only occasionally gives the owner time to see the sign-in alert in their email before the attacker can publish.

What it means for a maintainer with one account

Any solo maintainer who has ever used a recovery code because a laptop died, a phone was reset, or an authenticator app was migrated will now see a three-day publishing pause the next time they use that fallback. If a critical patch has to be released during those three days, the account can sign in and read, but not publish. Support has no way to shorten the hold.

The practical adjustment is small but real: keep a working second factor on the account, so recovery codes stay a rare fallback. And if a patch is time-sensitive, do the second-factor swap early, so you do not have to use the fallback while a fix is waiting in a branch.

npm's guidance for the reverse case is worth stating: if you were blocked from publishing and did not use a recovery code, that means the hold is on your account without your action, and you should contact npm support right away, since the 72-hour timer will not end it any faster.

Source

GitHub changelog: npm extends recovery-code security holds to all accounts