- NIST's database lists CVE-2026-112775: Craft CMS 5.0.0 to before 5.11.0 lets an emailed verification code be reused to reset a password and take over an account.
- The flaw matters because a code that confirms an email address also works as a password-reset key after it has been used.
- Teams running Craft CMS 5 should check their version, confirm the fix in the vendor advisory, move to a version outside the affected range, and review recent email-change activity.
A verification code should work once. After that, it should be worth nothing. A new record in the NIST National Vulnerability Database says Craft CMS breaks that rule in some versions, and the result is account takeover.
The record, CVE-2026-112775, was published on October 19, 2026. It covers Craft CMS from 5.0.0 up to, but not including, 5.11.0. The scores come from VulnCheck. It rates the flaw 7.5 (High) under CVSS 3.1 and 8.7 (High) under CVSS 4.0. CVSS is the standard scale for rating how serious a software flaw is.
How the flaw works
Craft CMS is a content management system. Like most, it emails users a code to confirm things, such as a new email address.
Two parts of Craft matter here. The first is an endpoint called users/verify-email, which checks the code when a person confirms an email change. The second is users/set-password, which lets someone choose a new password using a code.
According to the record, verify-email does not invalidate the code for active users. The code stays alive after it has done its job.
That leaves a gap. Suppose a user changes their email address and confirms it with the emailed code. An attacker who has that same code can then send it to set-password. The password is reset, and the attacker owns the account.
The code was meant to prove one thing: that the person controls a mailbox. It ends up working as a password-reset key for the account.
A key that outlives its purpose
Think of a hotel key card that still opens the room after checkout. Nobody picked the lock. The card simply was not switched off.
This is the idea worth taking from the record. Many security failures are not about weak secrets. They are about secrets that stay valid longer than the task they were issued for. The code here is not guessed or forged. It is a real code, used at the right time, then left active.
This also changes where to look. In our view, login forms tend to get the most attention. Flows around them, such as email change, invitations and password recovery, issue credentials too. Each one needs a clear end of life.
What the record does not say
The scoring is worth reading closely. The CVSS vectors rate the attack as network-based, low in complexity, and needing no account and no action from the victim. They rate the impact as high for confidentiality only.
The description, however, says the attacker must first obtain the victim's emailed code. The record does not explain how an attacker would get it. It also does not report any exploitation, and it does not mention other Craft versions.
Those gaps matter for planning. The risk depends on how exposed your users' mailboxes and mail flows are, which the score cannot show. The NVD record points to a Craft CMS security advisory (GHSA-xh42-494x-2xgv) and a VulnCheck advisory. Your team should read both for fix details.
What to ask your team
Start with inventory. Does any site we run use Craft CMS 5, and which exact version? The record's affected range is 5.0.0 to before 5.11.0.
Next, ask about timing. When can we move to a version outside the affected range, 5.11.0 or later, once the advisory confirms the fix? Ask your developers to check the vendor advisory before choosing any workaround, and to say what covers the gap until then.
Then ask about evidence. Can we see requests to the set-password endpoint that follow a recent email change? Were any accounts with wide access involved? Those accounts are the ones to check first.
Last, widen the question beyond Craft. For every code or link our systems email to users, do we know when it stops working? A one-time code only protects an account if the system treats it as one-time.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: NIST NVD.
