npm shipped a new protection this week for its most depended-on accounts. When npm detects a sensitive action on a high-impact account, like an email swap or the use of a 2FA recovery code, it puts that account into a 72-hour read-only state and sends an alert to the previous email address. The package installs and downloads keep working as normal during this time, and the freeze lifts automatically at the end of the waiting period.  

This update prevents actions that affect the registry or the account’s security, such as publishing, token management, package visibility changes, and org membership changes. It’s a registry-level control to quickly catch when an account starts to slip out of its owner's hands.

This is great, and is just the latest in a bunch of security improvements from npm. They gave us staged publishing in May and will block postinstall scripts by default in v12 in July. The defaults are slowly bending toward prevention and away from reaction. Microsoft has been cooking lately on security fixes, likely inspired by a string of malware attacks happening on its platforms (and to its platforms).

npm hasn’t restated a threshold for this feature, but it has used the term before. Its 2FA-enforcement policy defines a high-impact account as one managing packages with more than 1 million weekly downloads or 500 dependents, and the cooldown is likely using the same criteria.

The impetus for this change

The recent axios compromise in March and the Mastra attack just the other week are the clearest examples in recent memory about why this is needed. These attacks used social engineering campaigns against the target accounts to get access. In the case of axios, the attacker posed as a company founder and lured a lead maintainer into a video call. The call link contained a "your system is out of date" prompt that installed a remote access trojan (RAT), handing the attacker control of the victim’s machine and a live npm session. They changed the account email, then published two malicious versions of axios directly, avoiding the entire CI system. axios does about 100 million downloads a week.

This type of attack is mostly invisible to the registry, like the steps on Slack and the compromised machine. The email change is the one step in the sequence that npm has any view into. Attackers change emails because it severs the real owner's recovery path and redirects security alerts away from them.

How it fits with npm’s other security changes

The cooldown is even more useful when you consider alongside the two fixes that npm shipped in the year or so.

Trusted publishing removes long-lived tokens. Publishing authenticates through short-lived OIDC credentials scoped to a CI workflow, so there’s no long-standing token sitting on a machine for a RAT to steal. However, it does a whole lot of nothing when an attacker holds a live session and publishes directly.

Staged publishing, which we got last month, adds a human approval step. A package staged from CI doesn’t go live until a maintainer approves it with 2FA, so an automated workflow alone can’t push a release to the world. An attacker who controls the account can route around this by approving their own staged package, if the package has it enabled at all.

Together, trusted publishing handles stolen credentials, staged publishing handles unreviewed automated releases, and the cooldown handles the account takeover that the other two go around. Of course, this doesn’t solve everything, but if you have stage-only trusted publishing and tokens disabled, you’re preventing a good chunk of the publish-side paths attackers have been using.

What to do now

If you maintain a popular package, check that the email on your npm account is one you control and actually monitor (otherwise, you’re going to miss their email alert). Move to FIDO2 where you can. Treat an unexpected email-change notice as a security incident rather than spam or a bug. If you publish from CI, configure trusted publishing as stage-only and disable tokens, so every release goes through a human approval, and there’s no long-lived credential to steal. If you do get an unexpected email about an account change, contact npm support.

If you consume packages rather than publish them, congrats! You benefit without doing anything. Still, some packages won’t have all their safety measures enabled (many still don’t have these security settings enabled). Safe Chain by Aikido is a free, open-source wrapper for npm, npx, and yarn that checks every package for malware before install and enforces a waiting period on new versions, which catches a good share of compromised releases before they reach your machine.

It’s been great being able to write about positive changes to the package registries lately.