Submit #1004893: nocodb <2026.08.1 Race Condition

Signup enforced email uniqueness with a check-then-act sequence, so concurrent registration requests for one address could all pass the existence check and each create its own user record.

users.service.ts tested whether an address was already taken through the canonical-email and email lookups, then later inserted the new row via User.ts. The pair was neither wrapped in a transaction nor backed by a uniqueness constraint on the email or canonical-email columns of the metadata users table, and two deliberately slow bcrypt operations — salt generation and hashing at cost factor 10 — sat inside the window, so a batch of simultaneously released requests cleared the check together without any precise timing on the attacker's part. The existing defence against alias abuse, which canonicalizes the address and rejects plus-addressing, operates on the value of the address and offered no protection against concurrency.

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