CVE-2026-32700
Race Condition in Devise Confirmable Allows Email Confirmation Bypass
Publication date: 2026-03-18
Last updated on: 2026-03-26
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| heartcombo | devise | to 5.0.3 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-362 | The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': 'CVE-2026-32700 is a race condition vulnerability in the Confirmable module of the Devise Ruby gem, which is used for authentication in Rails applications. This vulnerability affects applications using the reconfirmable option, which is enabled by default when Confirmable is used with email changes.'}, {'type': 'paragraph', 'content': "The issue occurs when an attacker sends two concurrent email change requests. This causes a desynchronization between the confirmation_token and unconfirmed_email fields in the database. Specifically, the confirmation token is sent to an email address controlled by the attacker, but the unconfirmed_email field points to a victim's email address."}, {'type': 'paragraph', 'content': "When the attacker uses the confirmation token, the victim's email is confirmed on the attacker's account, effectively allowing the attacker to confirm an email address they do not own."}, {'type': 'paragraph', 'content': 'This vulnerability was patched in Devise version 5.0.3. The fix involves ensuring that the unconfirmed_email attribute is always marked as changed and persisted, preventing the race condition. Workarounds include overriding specific methods in the Devise model to force persistence of unconfirmed_email even if it has not changed.'}] [1, 2, 4]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability arises from a race condition in the Devise Confirmable module when using the reconfirmable option, causing desynchronization between the confirmation_token and unconfirmed_email fields. Detection involves monitoring for concurrent email change requests that could cause this desynchronization.
There are no specific network or system commands provided in the available resources to detect this vulnerability directly.
However, detection could involve reviewing application logs for concurrent email change requests or inspecting the database for inconsistent states where confirmation_token and unconfirmed_email fields do not match expected values.
What immediate steps should I take to mitigate this vulnerability?
[{'type': 'paragraph', 'content': 'The primary mitigation is to upgrade Devise to version 5.0.3 or later, where this race condition vulnerability is patched.'}, {'type': 'paragraph', 'content': 'As a workaround, applications can override the method postpone_email_change_until_confirmation_and_regenerate_confirmation_token in their Devise models (e.g., User model) to force the unconfirmed_email attribute to be marked as changed and persisted even if it has not actually changed.'}, {'type': 'list_item', 'content': 'Override the method as follows in your User model: \n```ruby\nclass User < ApplicationRecord\n protected\n def postpone_email_change_until_confirmation_and_regenerate_confirmation_token\n unconfirmed_email_will_change!\n super\n end\nend\n```'}, {'type': 'paragraph', 'content': 'For Mongoid users, since the will_change! method may not force persistence as expected, an additional workaround is required by manually setting changed_attributes["unconfirmed_email"] = nil to ensure the change is persisted.'}] [1, 2, 4]
How can this vulnerability impact me? :
[{'type': 'paragraph', 'content': "This vulnerability can allow an attacker to confirm an email address they do not own on their own account within a Devise-based application. By exploiting the race condition, the attacker can link a victim's email address to their account without the victim's consent."}, {'type': 'paragraph', 'content': 'This can lead to unauthorized account access or manipulation, as the attacker effectively verifies control over an email address that belongs to someone else. This undermines the integrity of the email confirmation process and can facilitate further attacks or account hijacking.'}, {'type': 'paragraph', 'content': 'Applications using Devise with the reconfirmable option enabled are vulnerable if they do not upgrade to version 5.0.3 or apply the recommended workarounds.'}] [1, 2, 4]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know