CVE-2026-21622: Non-Expiring Reset Tokens in Hex.pm

CVE-2026-21622 is a critical insufficient session expiration flaw (CVSS 9.8) in hexpm, the software behind the Hex package registry for Elixir and Erlang. Password reset tokens never expired. The fix is commit bb0e420, and the service fix landed on 5 March 2026. If you suspect leaked email, reset your password and enable 2FA.

What's affected

The record and the Erlang Ecosystem Foundation CNA entry say hexpm is affected from commit 617e44c up to but not including commit bb0e420, which is the fix. For the hosted service at hex.pm, the entry lists the affected window as from 1 August 2025 until 5 March 2026. The weakness is CWE-613 (insufficient session expiration). The NVD vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The CNA scores it 9.5 using the newer CVSS 4.0 scale.

The flaw is in the PasswordReset module of the hexpm server. The advisory describes reset links sent by email whose tokens stayed valid until used, with no time limit. If you only use packages from hex.pm, the registry operators fixed the service. If you run your own hexpm server, you must update it yourself.

The record does not mark the issue as exploited in the wild, and it is not in the CISA Known Exploited Vulnerabilities catalog.

How to check if you're exposed

If you publish packages on hex.pm, ask a simple question: could an old password reset email still be sitting in a mailbox that someone else could read now, such as an old backup, a leaked archive or a shared inbox? Search your own mailbox for reset emails from Hex, and check whether any were never used.

If you self host hexpm, check which commit your server runs. From your deployment checkout:

git merge-base --is-ancestor bb0e42091995945deef10556f58d046a52eb7884 HEAD && echo "fix present" || echo "fix missing"

Check the owners and recent releases of your own packages on hex.pm for anything you did not publish.

What to do now

1. If you may have had a mailbox leak, reset your Hex password now. A fresh reset invalidates older tokens that were never used.
2. Enable and enforce two factor authentication on your Hex account. The advisory lists it as a workaround, and it blocks a reset on its own from taking over publishing rights.
3. Review your package owners and recent releases on hex.pm, and revoke API keys you do not use.
4. Delete old password reset emails from mailboxes and archives you control.
5. If you self host hexpm, update to a build that includes commit bb0e420 and test the reset flow.
6. Pin and verify dependencies in your Elixir and Erlang projects with your lockfile so that an unexpected release does not install by surprise.

Why it matters

A reset token is a temporary key. It is supposed to be useful for a short window after you ask for it. Without an expiry, an email sent years ago still works until someone uses it, and a mailbox that leaks later turns into a pile of old keys. The attacker needs no access to the victim's current email, only to a copy of the old message, which is the scenario the advisory describes.

For a package registry, the stakes are higher than for most sites. An account takeover on a registry can mean a malicious release of a library that thousands of projects install. That is the reason the credit score is critical and why the advisory recommends 2FA.

The fix is to enforce a time limit when a token is checked. The lesson for any application is to give every token an expiry and a single use, and to test that an old token fails. Continuous monitoring of the packages you depend on, as in the demo, tells you when a new release appears.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• GitHub advisory GHSA-6r94-pvwf-mxqm for hexpm
• EEF CNA entry for CVE-2026-21622
• Fix commit bb0e420 in the hexpm repository
• NVD record for CVE-2026-21622

Last reviewed: 19 October 2026.