CVE-2026-32700: 
Ruby vulnerability analysis and mitigation

CVE-2026-32700 is a race condition vulnerability in Devise's Confirmable module that allows an authenticated attacker to confirm an email address they do not own. It affects all versions of the Devise RubyGem (for Ruby on Rails) up to and including 5.0.2, specifically applications using the reconfirmable option (the default when Confirmable is enabled). The vulnerability was originally reported by researcher grantcox on July 7, 2025, and publicly disclosed on March 16, 2026, after 90 days of no response from maintainers. It carries a CVSS v3.1 score of 5.3 (Medium) and a CVSS v4.0 score of 6.0 (Medium) (GitHub Advisory, Red Hat Bugzilla).

The root cause is a Time-of-Check Time-of-Use (TOCTOU) race condition (CWE-362, CWE-367) in the postpone_email_change_until_confirmation_and_regenerate_confirmation_token method of Devise's Confirmable module. When an attacker sends two concurrent email change requests — one to an email they previously set (attacker2@email.com) and one to a victim's email — the first request's SQL UPDATE omits the unconfirmed_email field because ActiveRecord considers it unchanged (it matches the in-memory model state), updating only the confirmation_token. If the victim-targeting request completes first, it sets both fields correctly; the subsequent attacker request then overwrites only the token, leaving the database in a desynchronized state where confirmation_token points to the attacker's email but unconfirmed_email holds the victim's address. When the attacker uses the received token, the victim's email is confirmed on the attacker's account (GitHub Advisory, Devise Issue #5783). Exploitation requires a low-privilege authenticated account and network access, but no user interaction from the victim (GitHub Advisory).

Successful exploitation allows an attacker to associate a victim's email address with their own account, effectively hijacking the victim's email identity within the application. This is a high-integrity impact with no confidentiality or availability consequences — the attacker gains unauthorized control over account identity data, which could enable account takeover if the application uses email as a primary authentication or recovery mechanism. Downstream effects may include bypassing email-based access controls, impersonating the victim within the application, or gaining access to services linked to the victim's email (GitHub Advisory, Red Hat Bugzilla).

No public exploit code or active in-the-wild exploitation has been reported as of the time of disclosure. The EPSS score is approximately 0.063% (0.019% per GitHub Advisory), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires timing precision to win the race condition, making it moderately complex, though the technique is well-understood in the context of concurrent HTTP request attacks (e.g., HTTP/2 single-packet attacks as described in PortSwigger research referenced in the advisory) (GitHub Advisory, Devise Security Advisory).

1. Register attacker account: Create an account on the target Rails application using an attacker-controlled email (e.g., attacker1@email.com).
2. Pre-set unconfirmed email: Change the account email to a second attacker-controlled address (e.g., attacker2@email.com) but do not confirm it. This sets unconfirmed_email to attacker2@email.com in the database.
3. Identify victim email: Determine the target victim's email address (victim@email.com) through any available means (e.g., public profile, enumeration).
4. Send concurrent requests: Using a tool capable of simultaneous HTTP requests (e.g., Burp Suite's parallel requests feature, HTTP/2 single-packet attack, or a custom script), send two concurrent email change requests: (a) one changing email back to attacker2@email.com, and (b) one changing email to victim@email.com.
5. Exploit the race condition: If request (b) completes first, the database is updated with unconfirmed_email = victim@email.com and a new confirmation_token. Request (a) then fires and, because attacker2@email.com matches the in-memory model's unconfirmed_email, ActiveRecord skips persisting unconfirmed_email and only updates confirmation_token — sending the new token to attacker2@email.com.
6. Confirm victim's email: Use the confirmation token received at attacker2@email.com to confirm the email change. The application confirms victim@email.com on the attacker's account, completing the email hijack (GitHub Advisory, Devise Issue #5783).

• Logs: Application logs showing two near-simultaneous POST requests to the email change endpoint (e.g., /users/registrations or equivalent) from the same authenticated session or IP address within milliseconds of each other.
• Logs: Confirmation email delivery logs showing a confirmation token sent to one email address while the unconfirmed_email database field holds a different address.
• Database: Mismatch between the email address that received the confirmation token and the unconfirmed_email value stored in the users table at the time of confirmation.
• Application Behavior: An account's confirmed email address changing to one that was never directly requested by that account's session, or a user reporting they did not initiate an email change but their email was altered.

Upgrade to Devise v5.0.3 or later, which fixes the race condition by ensuring unconfirmed_email is always included in the SQL UPDATE statement regardless of whether its in-memory value appears unchanged (GitHub Advisory, Devise PR #5784). For applications that cannot immediately upgrade, override the postpone_email_change_until_confirmation_and_regenerate_confirmation_token method in your model to call unconfirmed_email_will_change! before invoking super. Mongoid users must additionally set changed_attributes["unconfirmed_email"] = nil to force persistence, as Mongoid does not honor will_change! for unchanged attributes (Devise Security Advisory).

The vulnerability was originally reported privately by researcher grantcox in July 2025, but after 90 days without a response from maintainers, it was disclosed publicly via a GitHub issue. Maintainer carlosantoniodasilva acknowledged the issue and noted it had been reported multiple times over prior years, apologizing for the delayed response. The advisory references a similar prior vulnerability in GitLab (CVE-2022-4037) and PortSwigger's research on "smashing the state machine," indicating the attack class is well-known in the security community (Devise Issue #5783, Devise Security Advisory).