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).
History

Tue, 29 Sep 2026 16:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

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


Mon, 28 Sep 2026 20:15:00 +0000

Type Values Removed Values Added
First Time appeared Circl
Circl vulnerability-lookup
Vendors & Products Circl
Circl vulnerability-lookup

Sun, 27 Sep 2026 15:00:00 +0000

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'}


cve-icon MITRE

Status: PUBLISHED

Assigner: CIRCL

Published: 2026-09-27T14:47:57.012Z

Updated: 2026-09-29T15:28:11.374Z

Reserved: 2026-09-27T14:47:50.804Z

Link: CVE-2026-101041

cve-icon Vulnrichment

Updated: 2026-09-29T15:26:29.914Z

cve-icon NVD

Status : Deferred

Published: 2026-09-27T15:16:27.190

Modified: 2026-09-29T16:17:05.510

Link: CVE-2026-101041

cve-icon Redhat

No data.