Require 2FA confirmation to change email, issue token, alter 2FA methods

[corneliusroemer]

🏷️ Discussion Type

Product Feedback / Security

Body

The axios/axios incident was possible partly because npm gives full privileges to session tokens, even when 2FA is enabled: One can change email, remove 2FA, issue tokens when one is logged in without nom requiring any sort of renewed authentication like password or 2FA token.

This is bad. For such sensitive operations, having a session token should not be enough. You should require a new 2FA token.

Another weakness: as long as one is logged in, one can see one's recovery codes. Recovery codes should only be shown the first time one adds a security key. Or at least require providing a 2FA token.

Current implementation of 2FA hardening seems half-hearted.

Per the docs, removing 2FA via CLI requires both password and 2FA token (as it should). But this doesn't help if the web interface doesn't require it (and it doesn't): https://docs.npmjs.com/configuring-two-factor-authentication#removing-2fa-from-the-command-line

Related:

• Expose audit log as a page on npmjs.com: https://github.com/orgs/community/discussions/191710

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[DanielRuf]

This also applies to the npm CLI with npm profile ... and other commands (and not just npmjs):

https://docs.npmjs.com/cli/v11/commands
https://docs.npmjs.com/cli/v11/commands/npm-profile

Basically any command that changes something in the registry:
https://docs.npmjs.com/cli/v11/commands/npm-adduser
https://docs.npmjs.com/cli/v11/commands/npm-deprecate
https://docs.npmjs.com/cli/v11/commands/npm-org
https://docs.npmjs.com/cli/v11/commands/npm-owner
https://docs.npmjs.com/cli/v11/commands/npm-publish
https://docs.npmjs.com/cli/v11/commands/npm-team
https://docs.npmjs.com/cli/v11/commands/npm-unpublish

I am aware, that npmjs and npm CLI were designed like that in the past by Isaac and the team.
But the 2FA enforcement should be more strict and any of these actions ask for some sort of credential again, even if npm login already happened and the token is stored in .npmrc.

[DanielRuf]

Another weakness: as long as one is logged in, one can see one's recovery codes. Recovery codes should only be shown the first time one adds a security key.

Definitely, like it is already case here on GitHub.

[daiyam]

Current implementation of 2FA hardening seems half-hearted.

Yep, allowing to remove 2FA without re-authenticating the user, it's bad, very bad.

[davex-ai]

hey @corneliusroemer

This is a critical assessment of a "failure by design" in npm’s security model. The Axios compromise in late March 2026 serves as a stark validation of your point: the attacker hijacked a lead maintainer's account and published malicious versions (v1.14.1 and v0.30.4) within 39 minutes.
The systemic weaknesses you've identified directly enabled the scale of this attack:

1. Session Token Over-Privilege

The current npm implementation allows an active session token—obtained via a compromised browser or machine—to perform highly sensitive "account-level" changes without re-authentication.

• The Axios Case: The attacker was able to change the maintainer's registered email to an attacker-controlled ProtonMail address (ifstap@proton.me) and subsequently publish malicious builds.
• The Failure: If npm required a fresh 2FA token for email changes or 2FA removal, the attacker (who had a session via a Remote Access Trojan) might have been blocked despite having the initial login access.

2. Recovery Code Visibility

You are correct that recovery codes remain accessible to anyone with an active login session.

• Current [npm documentation](https://docs.npmjs.com/recovering-your-2fa-enabled-account/) confirms that users can "view and regenerate" codes simply by navigating to the 2FA settings page while logged in.
• In the Axios incident, there was speculation that recovery codes might have been used to maintain or finalize the takeover, highlighting that these "master keys" are too easily retrievable for an attacker with a hijacked session.

3. Web vs. CLI Discrepancy

There is a clear gap in "hardening" between the two interfaces:

• CLI Protection: The npm profile docs state that disabling 2FA via the command line does require a password and 2FA token.
• Web Vulnerability: The web interface allows for 2FA modification or disabling with significantly fewer friction points if a session is already active, which is exactly what a browser-based RAT exploits.

Summary of Suggested Fixes

To move beyond "half-hearted" implementation, the community consensus (as seen in recent [GitHub community discussions](https://github.com/orgs/community/discussions/191503)) is pushing for:

• Mandatory Sudo Mode: Requiring a fresh 2FA token/password for any change to email, 2FA settings, or password.
• Recovery Code Blindness: Masking recovery codes after the initial setup or requiring 2FA to reveal them.
• Token Scoping: Ensuring session tokens cannot be used to issue new, long-lived access tokens without secondary verification.

Pls Upvote if this helps