CVE-2026-32700

What it actually does

Devise versions prior to 5.0.3 contain a race condition in the Confirmable module when the reconfirmable email-change workflow is enabled. By submitting concurrent email-change requests, an authenticated attacker can cause the stored confirmation_token and unconfirmed_email values to become desynchronized. The token is delivered to an attacker-controlled email address, while the pending email value can point to a victim email address. When the attacker redeems the token, Devise may mark the victim email address as confirmed on the attacker’s account. The issue affects account identity integrity rather than confidentiality or availability and requires an attacker to have a valid account and win a timing race.

Why it matters to the business

Applications that rely on verified email addresses for trust, account recovery, eligibility, invitations, billing, or identity workflows may incorrectly associate an attacker-controlled account with another person’s email address. This can lead to user impersonation, abuse of email-based authorization logic, account confusion, support burden, compliance concerns, and downstream fraud risk. Although exploitation is not currently known to be widespread and EPSS is low, affected Rails applications using Devise Confirmable with reconfirmable email changes should still patch promptly because authentication components are high-value and the bug can undermine identity assurance.

How an attack unfolds

An attacker first creates or uses a legitimate account in a Rails application that uses Devise Confirmable with reconfirmable email changes. The attacker then submits two email-change requests at nearly the same time: one involving an email address they control and another involving a target email address they do not control. Because vulnerable Devise versions do not consistently persist the pending unconfirmed_email value during this race, the confirmation token and pending email can become mismatched. The application sends a valid confirmation link to the attacker-controlled mailbox, but the database can retain the victim email address as the pending email. The attacker follows the confirmation link they received, and the application confirms the victim email address on the attacker’s account. The attacker may then use application features that treat confirmed email ownership as proof of identity or entitlement.

How to fix it

Upgrade Devise to version 5.0.3 or later wherever Devise Confirmable is used, especially applications using reconfirmable email changes. Review Gemfile.lock and deployed artifact manifests to ensure the runtime version is actually updated, then redeploy and restart Rails application processes. If immediate upgrade is not possible, apply the vendor-recommended workaround by overriding the affected Devise model behavior so unconfirmed_email is forcibly persisted even when unchanged. For Mongoid-backed applications, also account for the noted behavior where will_change! may not force persistence; implement the equivalent workaround by setting changed_attributes["unconfirmed_email"] = nil or the vendor-recommended pattern for the application’s persistence layer. As a defense-in-depth measure, consider serializing or rate-limiting email-change requests per account, preventing simultaneous email-change submissions, and adding audit logging for old email, new email, confirmation token issuance, and confirmation completion events.

How to confirm the fix worked

Confirm that the deployed application resolves Devise to version 5.0.3 or later, for example by checking Gemfile.lock, bundle info devise, container image SBOMs, build logs, or runtime dependency inventories. Verify whether Confirmable and reconfirmable are enabled in Devise model configuration. In a non-production test environment, attempt concurrent email-change submissions against a test account and confirm that the token and pending email cannot be desynchronized and that the confirmed email is always the address that received the token. Validate that email-change requests are serialized or safely handled under concurrent load. Review tests to ensure the reconfirmation flow persists unconfirmed_email consistently across ActiveRecord or Mongoid as applicable.

Typical attack path

1. Register or authenticate to a valid account in an application using vulnerable Devise Confirmable reconfirmation behavior.
2. Identify the email-change workflow and confirmation-link behavior.
3. Send two carefully timed concurrent email-change requests: one for an attacker-controlled address and one for the victim address.
4. Receive a confirmation email containing a valid confirmation token at the attacker-controlled mailbox.
5. Redeem the confirmation token before the inconsistency is corrected or noticed.
6. Obtain an account state where the attacker’s account has the victim email address marked as confirmed.
7. Abuse application features that trust confirmed email ownership, such as invitations, recovery flows, access eligibility, or identity verification.

How to detect it

Investigate application audit logs, Rails request logs, authentication event logs, database change history if available, and mail delivery logs. Look for accounts with two or more email-change requests occurring within the same second or very small time window, especially where different target email addresses were submitted. Correlate outbound confirmation emails with subsequent confirmation-token redemption and verify that the confirmed email matches the mailbox that received the token. Pay particular attention to sequences where one email-change request targets an attacker-controlled address, another targets a different address, and the confirmation request is completed shortly afterward from the same account, IP address, session, or user agent. Review records where confirmed_at changed shortly after unconfirmed_email changed, where unconfirmed_email and email transitions appear inconsistent, or where support complaints report unexpected email ownership conflicts. Since public exploitation is not currently established and there are no known malware artifacts for this issue, detection should focus on behavioral anomalies in the email-change and confirmation workflow rather than file or process indicators.

• confirmation_token=
• /confirmation?confirmation_token=
• GET /users/confirmation
• PATCH /users
• PUT /users
• unconfirmed_email
• confirmation_token
• confirmed_at
• Confirmable
• reconfirmable
• changed_attributes["unconfirmed_email"]

What your security team should do

• Inventory Rails applications and services using the heartcombo devise gem and identify those running versions earlier than 5.0.3.
• Prioritize patching authentication-facing applications, internet-accessible user portals, customer identity systems, and applications where confirmed email controls access, account recovery, billing, or authorization decisions.
• Upgrade Devise to 5.0.3 or later and redeploy all affected application instances, workers, and containers.
• If patching is delayed, implement the documented model override workaround and add per-account locking or request throttling around email-change actions.
• Search application logs, audit logs, and mail delivery logs for suspicious concurrent email-change activity and confirmation events involving different addresses for the same account in a short time window.
• Add monitoring for repeated or simultaneous email-change requests from the same account, IP address, session, or user agent.
• Review application logic that treats confirmed email ownership as authorization and add compensating checks where email identity is security-sensitive.
• Force review or re-verification of accounts with anomalous recent email-change and confirmation patterns if exploitation is suspected.