Submit #1004891: nocodb < 2026.08.1 Race Condition

users.service.ts handled a reset by reading the user row keyed on reset_password_token, checking the expiry and the account's auth provider, hashing the submitted password, and only then issuing an unconditional update that cleared the token. The read and the clearing write were neither wrapped in a transaction nor expressed as a conditional update, so nothing tied the clear to the row state that had been validated. Two deliberately slow bcrypt operations, salt generation and hashing at cost factor 10, sat between the two, holding the window open long enough that a batch of simultaneously released requests all passed validation before any of them cleared the token; each then went on to write a password, emit a password-reset audit event and return success. Sequential replay of a consumed token was rejected correctly — the defect was strictly concurrent.

• Source: ⚠️ https://github.com/nocodb/nocodb/issues/14684
• User: ZAST.AI (UID 87884)
• Submission: 09/29/2026 10:43 (27 days ago)
• Moderation: 10/25/2026 10:23 (26 days later)
• Status: Accepted
• VulDB entry: 426187 [NocoDB up to 2026.08.0 Password-Reset Flow users.service.ts race condition]
• Points: 20