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.

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.

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.