High-impact packages need stronger publish controls

[vaibhavdagar]

The axios supply chain attack on March 31, 2026 exposed a fundamental gap in how npm handles publishing for high-impact packages. A single compromised account was enough to push malicious code to 100M+ weekly downloads with zero friction and zero delay.

We'd like NPM to formally consider the following:

1. Mandatory publish confirmation via 2FA for packages above a certain download threshold
2. Cool-off periods before newly published versions become resolvable
3. Postinstall scripts opt-in by default, not opt-out
4. Recovery codes should not be able to change account email and trigger a publish in the same session without secondary confirmation
5. OIDC-only publishing for high-impact packages , long-lived tokens should not be an option

[jan-swiecki]

I think there should additionally be a feature to install not-the-newest-version of a package. Conceptually something like npm install axios@"1 month old". This requires releases to be immutable, but AFAIK they are.

[Marq91]

@vaibhavdagar I don't know if the npm CLI provides secure commands; something like what you do with ssh would be a good option. What do you think?

[ljharb]

That feature (a cool-off period) already exists.

Additionally, what you're describing is not new information to anyone, and it will always be possible since most open source has a single maintainer.

OIDC is one-factor, so requiring it (for anyone) would be LESS secure than the alternative.

[vaibhavdagar]

That feature (a cool-off period) already exists.

Additionally, what you're describing is not new information to anyone, and it will always be possible since most open source has a single maintainer.

OIDC is one-factor, so requiring it (for anyone) would be LESS secure than the alternative.

axios/axios#10604 (comment)

[ljharb]

I'm quite familiar with axios' scenario, and OIDC is still one factor and not better. If, however, the axios maintainer only used 2FA and only published locally, the incident would have been impossible.