https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 08 Oct 2026 23:23:48 +0000 https://cve.radiocsirt.org/vuln/cve-2026-32700 <p><strong>Affected:</strong> heartcombo devise</p> <p>Devise is an authentication solution for Rails based on Warden. Prior to version 5.0.3, a race condition in Devise&#39;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&#39;s email address. When the attacker uses the token, the victim&#39;s email is confirmed on the attacker&#39;s account. This is patched in Devise v5.0.3. Users should upgrade as soon as possible. As a workaround, applications can override a specific method from Devise models to force `unconfirmed_email` to be persisted when unchanged. Note that Mongoid does not seem to respect that `will_change!` should force the attribute to be persisted, even if it did not really change, so the user might have to implement a workaround similar to Devise by setting `changed_attributes[&#34;unconfirmed_email&#34;] = nil` as well.</p> <p><strong>Affected:</strong> heartcombo devise</p> <p>Devise is an authentication solution for Rails based on Warden. Prior to version 5.0.3, a race condition in Devise&#39;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&#39;s email address. When the attacker uses the token, the victim&#39;s email is confirmed on the attacker&#39;s account. This is patched in Devise v5.0.3. Users should upgrade as soon as possible. As a workaround, applications can override a specific method from Devise models to force `unconfirmed_email` to be persisted when unchanged. Note that Mongoid does not seem to respect that `will_change!` should force the attribute to be persisted, even if it did not really change, so the user might have to implement a workaround similar to Devise by setting `changed_attributes[&#34;unconfirmed_email&#34;] = nil` as well.</p> https://cve.radiocsirt.org/vuln/cve-2026-32700