Safeguard
Vulnerability Analysis•

CVE-2025-22144: Critical Account Takeover in NamelessMC

CVE-2025-22144 is a critical account takeover in NamelessMC before 2.1.3 via an empty password reset code. Upgrade to 2.1.3; no workaround exists.

Safeguard Security Team
4 min read

CVE-2025-22144 is a critical account takeover flaw (CVSS 9.8) in NamelessMC, the website software for Minecraft servers, before version 2.1.3. Accounts validated manually get an empty password reset code instead of none, which lets someone reset their password. Upgrade to 2.1.3; there is no workaround.

What's affected

  • Product: NamelessMC, website software for Minecraft servers
  • Affected versions: before 2.1.3
  • Fixed version: 2.1.3, per the record and the project's release
  • Weakness: a reset code left empty instead of null after manual validation (CWE-640, CWE-610)
  • CVSS: 9.8 (Critical), vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
  • Published: 2025-01-13

The record says that when an account is approved by email, the reset code is NULL, but when a user with the admincp.core.emails or admincp.users.edit permission validates an account by hand, the reset code becomes an empty string instead. The advisory rates the impact as account takeover, and the record says there are no known workarounds. The CISA Known Exploited Vulnerabilities flag is false for this CVE, and none of the pages I read report active exploitation.

How to check if you're exposed

Check the version in the admin panel overview, or in the project files, and compare with 2.1.3.

If you are below 2.1.3, work out whether the issue could already have been used on your site.

  1. Make a list of accounts that staff validated manually, as opposed to accounts that confirmed through email.
  2. Look at those accounts for password changes you cannot explain, new sessions from unfamiliar places, and role changes.
  3. Review which staff hold the permissions admincp.core.emails and admincp.users.edit, since they are the ones who could trigger manual validation.
  4. Check access logs around the password reset route for unusual traffic.

You can also run our free in-browser dependency scan against the project's Composer files to see how the rest of the stack looks.

What to do now

  1. Upgrade NamelessMC to 2.1.3 or later. The record states there is no workaround, so the upgrade is the fix.
  2. Force a password reset for accounts that were validated manually while you ran an affected version.
  3. Review administrator and moderator accounts first, since those are the most valuable to take over.
  4. Reduce the number of people with the permissions to validate users, and review who holds them.
  5. Enable additional protection on privileged accounts where the software supports it, and watch sign in activity for a while.

Why it matters

The record lists CWE-640, weak password recovery for forgotten password, and CWE-610, externally controlled reference to a resource in another sphere. The recovery flow treats a code that is present but empty as a valid code, because the check was written for the case where the code is missing.

That is a small slip with a large effect. A password reset code is a secret, and an empty value is not a secret at all. The fix is in 2.1.3. Pay attention to the lesson as well: values that mean nothing, such as empty strings, zero and null, should be rejected explicitly wherever a code or token is compared.

Try it yourself

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

Quick check

Is there a workaround?

The record says there are no known workarounds. Upgrade to 2.1.3.

Who is affected?

Accounts validated manually by staff with the relevant permissions, on versions before 2.1.3, as described in the record.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.