Race Condition 101: How I Exploited a Real Bug Bounty Scenario to Break Backend Validation

3 min readJun 24, 2025

Hello again guys

First, I’m Kerolos Ayman — Bug Bounty Hunter and CTF player.

Today, I’m going to share a real-world bug bounty experience where I discovered a subtle but impactful race condition vulnerability.

What is a race condition?

A race condition occurs when the outcome of a process depends on the unpredictable order in which multiple threads or processes access and modify shared resources. This can lead to unexpected and potentially erroneous results, or even security vulnerabilities. Essentially, it’s a “race” to access a resource, and the order in which they arrive determines the outcome.

Race conditions can result in:

Duplicate resource creation
Bypassing business logic validation
Unexpected privilege escalation
Data corruption or leakage

It’s important to note that when testing for race conditions, the success rate of your concurrent requests can vary greatly depending on the target application’s infrastructure, backend implementation, and how quickly it processes requests.
For example:
On one target, out of 10 concurrent requests, you might get 3 or 4 to succeed. On another, all 10 might go through — or none at all. It’s unpredictable, and that’s part of what makes race condition hunting both challenging and interesting.

Let’s assume the target is example.com

While testing the event creation functionality on example.com, I noticed the following behavior:

When creating a new event, the application asked for an event name.
If the name already existed, the frontend would display a message:
“That name is already taken. Please choose a different name.”

This made me wonder:
What happens if I send multiple requests at the same time, before the backend finishes validating and locking the name?

Exploitation Method

I decided to test for a simple race condition using Burp Suite Repeater — You can use Turbo Intruder extension too. Here’s the exact process I followed:

Login to my account
Navigated to the event creation page.
Chose a unique, unlikely-to-exist name:
KeroTest9999999990000000
Captured the POST request in Burp Suite and send it to Burp Repeater.
Made 11 identical requests using Burp Repeater, put them in a group and sent them in parallel (single — packet attack).
Checked the events list page.

To my surprise — 3 out of 11 requests succeeded in creating events with the exact same name.

Results

The application’s frontend validation was bypassed.
The backend failed to enforce the unique constraint when handling concurrent requests.
Multiple events with the same name now appeared in the events list.

I submitted the report and got triaged alhamdalalah.