vulnerability-lookup EUVD-2026-87956

Exploitation requires the attacker to already hold a VALID, unconsumed single-use recovery token for the target account (issued via the account confirmation/password-reset flow); without a live token the endpoint cannot be driven. The attacker must then send two or more simultaneous requests to /user/confirm_account/<token> and win the narrow check-then-consume race window before the first transaction commits (hence AC:H). No login/authentication to the application is required (PR:N) and no user interaction from the victim is needed at exploit time. Limiting factors: the token prerequisite, the timing precision needed to win the race, and the fact that only pre-fix (unpatched) instances applying separate verify-then-clear operations are vulnerable - the fix collapses these into one conditional UPDATE. The secondary weak-password defect requires the same valid token and simply skips the form's minimum-length/complexity validation.

This is a genuine but moderate-severity flaw whose real-world priority is bounded by a hard prerequisite and by product footprint rather than by the 6.3 CVSS score alone. The vendor's CVSS 4.0 vector (AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L) correctly marks network vector, high attack complexity (winning a TOCTOU race requires precise concurrent timing) and no privileges, but the description makes clear the attacker must ALREADY possess a valid single-use recovery token - a condition CVSS captures only indirectly through AC:H, not through PR. EPSS is not provided, the CVE is not in CISA KEV, and no standalone weaponized exploit is published - only a regression test committed alongside the fix demonstrates the race. So there are no signals of active or automatable exploitation. I disagree with the vendor's VI:N: the outcome is overwriting a legitimate user's password (account integrity), which is an integrity impact, so I assess VI:L / I:L. The secondary defect (validation bypass allowing 3-character/empty passwords) further weakens account security but is low impact on its own. Net: a real, patch-worthy authentication-workflow bug, but low urgency given the token prerequisite, AC:H, absence of exploitation signals, and the niche deployment base.

An attacker who has obtained a valid, unexpired recovery token for a target account (e.g., an initial-confirmation link or a leaked reset link) fires two or more concurrent POST requests to /user/confirm_account/<token>, racing the check-then-consume window so more than one request passes nonce verification before any transaction commits. The last commit wins, letting the attacker set a password of their choosing - optionally an empty or 3-character one via the validation-bypass defect - on the account. No standalone public exploit exists, but the vendor's own regression test (test_account_token_race.py) reproduces the race using a thread barrier and two simultaneous clients.