CVE-2026-101041: Vulnerability-Lookup - Race Condition in Account Recovery Token Consumption Allows Password Takeover
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 (confirmaccount) 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/confirmaccount/<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).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Remove
Remove
dead consume_account_token() methodfrom your environment.Remove the dead consume_account_token() method to eliminate the non-atomic token-consumption path.
- Compensating control
Replace the non-atomic token check-then-consume flow with a single conditional UPDATE (compare-and-set) that atomically verifies the stored SHA-256 nonce digest, updates the password hash, sets is_confirmed, and clears the token.
- Compensating control
In the account recovery view handler, call form.validate() before processing the password change so the form's minimum-length, complexity, and password-equality validators are enforced.
Event History
Frequently Asked Questions
What must an attacker have to take over an account?
The attacker must possess a valid account-recovery token for the target account. They must send concurrent requests to the /user/confirm_account endpoint using that token; no prior account privileges or user interaction are required.
What makes the race condition exploitable?
The recovery token was verified and cleared in separate database operations. Two requests using the same valid token could both pass verification before either request committed, and the password from the last committed transaction would become the account password.
Is password policy enforcement bypassed during recovery?
Yes. The affected handler compared the two submitted password fields but did not invoke form validation, allowing an empty or trivially short password, such as a three-character password, when using a valid recovery link.
How can administrators identify potentially affected activity?
Review account-recovery activity for concurrent requests to /user/confirm_account using the same recovery token, particularly where password changes occurred in rapid succession. The provided data does not identify a specific logging field or audit record for detecting this.
What fixes are referenced?
Two upstream commits are referenced: 5462bab62d76df852619e01eb67da36c023c8c40 and ad6f22882975516adf193a1a920aaa54025c71d4. The provided data does not state affected or fixed release versions.