CVE-2026-32700
ADVISORY - githubSummary
Impact
A race condition in Devise's Confirmable module allows an attacker to confirm an email address they do not own. This affects any Devise application using the reconfirmable option (the default when using Confirmable with email changes).
By sending two concurrent email change requests, an attacker can desynchronize the confirmation_token and unconfirmed_email fields. The confirmation token is sent to an email the attacker controls, but the unconfirmed_email in the database points to a victim's email address. When the attacker uses the token, the victim's email is confirmed on the attacker's account.
Patches
This is patched in Devise v5.0.3. Users should upgrade as soon as possible.
Workarounds
Applications can override this specific method from Devise models to force unconfirmed_email to be persisted when unchanged: (assuming your model is User)
class User < ApplicationRecord
protected
def postpone_email_change_until_confirmation_and_regenerate_confirmation_token
unconfirmed_email_will_change!
super
end
end
Note: Mongoid does not seem to respect that will_change! should force the attribute to be persisted, even if it did not really change, so you might have to implement a workaround similar to Devise by setting changed_attributes["unconfirmed_email"] = nil as well.
Common Weakness Enumeration (CWE)
Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Time-of-check Time-of-use (TOCTOU) Race Condition
GitHub
1.6
CVSS SCORE
6medium| Package | Type | OS Name | OS Version | Affected Ranges | Fix Versions |
|---|---|---|---|---|---|
| devise | gem | - | - | <=5.0.2 | 5.0.3 |
CVSS:4 Severity and metrics
The CVSS metrics represent different qualitative aspects of a vulnerability that impact the overall score, as defined by the CVSS Specification.
The vulnerable component is bound to the network stack, but the attack is limited at the protocol level to a logically adjacent topology. This can mean an attack must be launched from the same shared physical (e.g., Bluetooth or IEEE 802.11) or logical (e.g., local IP subnet) network, or from within a secure or otherwise limited administrative domain (e.g., MPLS, secure VPN to an administrative network zone). One example of an Adjacent attack would be an ARP (IPv4) or neighbor discovery (IPv6) flood leading to a denial of service on the local LAN segment (e.g., CVE-2013-6014).
A successful attack depends on conditions beyond the attacker's control, requiring investing a measurable amount of effort in research, preparation, or execution against the vulnerable component before a successful attack.
The successful attack does not depend on the deployment and execution conditions of the vulnerable system. The attacker can expect to be able to reach the vulnerability and execute the exploit under all or most instances of the vulnerability.
The attacker requires privileges that provide basic capabilities that are typically limited to settings and resources owned by a single low-privileged user. Alternatively, an attacker with Low privileges has the ability to access only non-sensitive resources.
The vulnerable system can be exploited without interaction from any human user, other than the attacker. Examples include: a remote attacker is able to send packets to a target system a locally authenticated attacker executes code to elevate privileges.
There is no loss of confidentiality within the Vulnerable System.
There is no loss of confidentiality within the Subsequent System or all confidentiality impact is constrained to the Vulnerable System.
There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the Vulnerable System. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the Vulnerable System.
There is no loss of integrity within the Subsequent System or all integrity impact is constrained to the Vulnerable System.
There is no impact to availability within the Vulnerable System.
There is no impact to availability within the Subsequent System or all availability impact is constrained to the Vulnerable System.
NIST
1.6
CVSS SCORE
6mediumDebian
-
Ubuntu
1.6
CVSS SCORE
5.3mediumRed Hat
1.6