🏁 Race Condition in Signicat Dashboard: Creating Duplicate Accounts Like a Pro

Hey everyone! Arya here (a.k.a. pelioro), back with another bug story from the field 🕵️‍♂️.
This time, I want to share how I found a race condition bug in the redacted.com dashboard that let me create multiple accounts with the same name, which shouldn’t be possible at all

\> Yep, no bounty involved — this was a VDP report — but the experience and the triage validation? 🔥 Worth it.

## 🎯 The Target: Redacted.com Dashboard

While exploring Signicat via their VDP program, I started checking their account creation feature inside the dashboard.

A simple form asking for a name and environment (sandbox or not) triggered my curiosity.

\> “What happens if I send the same request… super fast… many times?”

Spoiler alert: something very interesting happened 😏

## 🔍 Finding the Bug

### ✅ Expected behavior:
- Each account name must be unique.
- If you try to create two accounts with the same name, you should get 400 Bad Request.

### 🧨 Actual behavior (when raced):
- When I sent the same account creation request concurrently, some requests returned:
— 201 Created ✅
— while others returned 400 Bad Request ❌
- That means multiple accounts got created with the same name, which shouldn’t happen.

## 🛠️ Steps to Reproduce

1. Login to: https://dashboard.redacted.com
2. Intercept the account creation request using Burp Suite or another proxy
3. Capture a request with payload:

{
 "isSandbox": true,
 "name": "dummy"
}

4. Replay the exact same request concurrently (use Turbo Intruder, Burp Intruder, or a custom Python script with threading)
5. Observe the responses:
— Some: 201 Created (with unique account IDs)
— Others: 400 Bad Request (name already taken)
6. Try again, but send the requests sequentially — all will correctly return 400 Bad Request.

\> 🔁 The issue only happens under concurrent conditions.

## 🎯 The Root Cause

This is a classic race condition — the backend isn’t properly locking or checking for the existence of the name atomically across parallel requests.

So multiple processes “see” that the name is available at the same time, and allow creation.

## 💥 The Impact

This bug might sound small, but here’s what it could lead to:

- Account impersonation: attacker registers a name before another team
- Privilege confusion: two teams think they own “dummy” account
- Broken business logic: services relying on name-based mapping might break
- Resource abuse: duplicated configs, potential cost implications

Even worse, if the name is used as a subdomain or identifier — this can lead to hijack scenarios or collisions in external systems.

## 📩 The Disclosure

I reported this via their VDP, and here’s the triager response I got:

\> “We were able to reproduce your report and will forward it to redacted.com.
They will review your submission and come back to you as soon as possible.”*
\> — FrostWeaver*

## 😎 Final Thoughts

Even though this was just a VDP (no bounty), the joy of having my report reproduced and forwarded to the vendor is priceless.

This bug taught me:
- How to test for race conditions
- How to automate concurrent requests
- How small logic bugs can lead to big real-world issues