CVE-2026-101041

Vulnerability-Lookup - Race Condition in Account Recovery Token Consumption Allows Password Takeover

Published Sep 27, 2026 CVSS 4.0 · 6.3 Medium EPSS < 1% KEV · Not listed
Description
The account recovery (password reset) functionality in the vulnerability-lookup web application contains a time-of-check-to-time-of-use (TOCTOU) race condition in the consumption of single-use recovery tokens. The original implementation verified the token nonce against the stored digest and then consumed (cleared) it in separate database operations. Two concurrent HTTP requests presenting the same valid recovery token could both pass the verification check before either transaction committed, allowing both to set their own password on the target account. The last transaction to commit overwrites the first, enabling an attacker who possesses a valid recovery token to replace the legitimate user's password with one of their choosing.

A secondary defect in the same endpoint (confirm_account) allowed a valid recovery link to be used to set an empty or trivially short password (e.g., three characters). The view handler performed only a manual equality comparison between the two password fields and never invoked the form's validation logic, bypassing the intended minimum-length and complexity constraints.

The affected component is the user account recovery endpoint (/user/confirm_account/<token>) and the associated token verification and consumption logic in the User model (website/models/user.py) and the view layer (website/web/views/user.py).

Analysis

AI-generated

Technical impact

The account recovery mechanism in the vulnerability-lookup web application contains a time‑of‑check‑to‑time‑of‑use race condition. The system verifies a token’s nonce before clearing it in separate database operations, allowing two simultaneous requests with the same valid token to both pass the check. This gives an attacker who possesses that recovery token the ability to set a new password on the victim’s account, and the final commit will overwrite the first change. A secondary flaw allowed the endpoint to accept an empty or very short password, bypassing length constraints. The result is that an attacker can take over user accounts after exfiltrating the temporary recovery token.

Affected Systems

Vulnerability‑lookup web application’s account recovery endpoint (/user/confirm_account/<token>) and the associated token verification logic in the User model and view layer. No specific version numbers are supplied, so any installation of this component that uses the legacy token consumption flow is potentially affected.

Risk and Exploitability

With a CVSS score of 6.3 the vulnerability is classified as medium. The EPSS score is not available and it is not listed in the CISA KEV catalog. The attack requires an attacker who already has a valid password‑reset token and the ability to send concurrent HTTP requests to the confirm_account endpoint. Successful exploitation would give the attacker full control over the targeted user account, allowing them to impersonate the user, access confidential data, and potentially pivot to other systems.

Remediation

Vendor Solution

The non-atomic check-then-consume pattern is replaced with a single conditional UPDATE statement (compare-and-set) that atomically verifies the stored SHA-256 nonce digest, updates the password hash, sets is_confirmed, and clears the token in one database operation. Only the first transaction to commit succeeds; all concurrent attempts match zero rows and are rejected with an error. The view now calls form.validate() before processing the password change, enforcing the form's length and equality validators. The dead consume_account_token() method is removed to eliminate the non-atomic consumption path entirely.


OpenCVE Recommended Actions

  • Apply the vendor patch that replaces the non‑atomic check‑then‑consume logic with a single conditional UPDATE (compare‑and‑set) operation, ensuring that only the first transaction consuming the token succeeds.
  • Confirm that the updated code changes invoke form.validate() to enforce password length and complexity before processing the change.
  • Verify that the dead consume_account_token() method has been removed and that the confirm_account endpoint no longer accepts empty or trivially short passwords.

Generated by OpenCVE AI on September 27, 2026 at 16:50 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories available
History
Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Type Values Removed Values Added
First Time appeared Circl
Circl vulnerability-lookup
Vendors & Products Circl
Circl vulnerability-lookup
Type Values Removed Values Added
Description The account recovery (password reset) functionality in the vulnerability-lookup web application contains a time-of-check-to-time-of-use (TOCTOU) race condition in the consumption of single-use recovery tokens. The original implementation verified the token nonce against the stored digest and then consumed (cleared) it in separate database operations. Two concurrent HTTP requests presenting the same valid recovery token could both pass the verification check before either transaction committed, allowing both to set their own password on the target account. The last transaction to commit overwrites the first, enabling an attacker who possesses a valid recovery token to replace the legitimate user's password with one of their choosing. A secondary defect in the same endpoint (confirm_account) allowed a valid recovery link to be used to set an empty or trivially short password (e.g., three characters). The view handler performed only a manual equality comparison between the two password fields and never invoked the form's validation logic, bypassing the intended minimum-length and complexity constraints. The affected component is the user account recovery endpoint (/user/confirm_account/<token>) and the associated token verification and consumption logic in the User model (website/models/user.py) and the view layer (website/web/views/user.py).
Title Vulnerability-Lookup - Race Condition in Account Recovery Token Consumption Allows Password Takeover
Weaknesses CWE-20
CWE-362
References
Metrics cvssV4_0

{'score': 6.3, 'vector': 'CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N'}

Weaknesses
  • CWE-20

    Improper Input Validation

  • CWE-362

    Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

Sources

Status
PUBLISHED
Assigner
CIRCL
Published
Updated
Sep 29, 2026, 3:28 PM
Reserved
Sep 27, 2026, 2:47 PM
Status
Deferred
Published
Sep 27, 2026, 3:16 PM
Modified
Sep 29, 2026, 4:17 PM