How I Found a Race Condition in an Email Verification Feature

When I started testing example.com, I wasn't looking for a race condition.

I was simply reviewing the account onboarding process like I usually do during a bug bounty assessment.

One feature caught my attention: "Resend Verification Email."

After clicking the button, it became disabled for 60 seconds.

Everything looked normal.

But then I asked myself a question that I ask very often during testing:

"Is this restriction enforced by the server, or only by the frontend?"

That question completely changed the story Looking Behind the UI

The user interface prevented me from clicking the button again for one minute.

Many applications do this to improve the user experience.

But a disabled button is not a security control.

The real protection should always exist on the server.

So instead of waiting one minute, I intercepted the request with Burp Suite.

The request looked similar to this:

POST /dashboard/api/verification-email/resend HTTP/2
Host: example.com
{}

POST /dashboard/api/verification-email/resend HTTP/2
Host: example.com
{}

Nothing unusual so far.

Testing the Feature :

The one-minute cooldown looked like a good security measure.

Still, I wondered:

"What if the server isn't enforcing it?"

I intercepted the request using Burp Suite and sent it to Turbo Intruder.

Then, I configured 12 parallel requests and launched them at the same time.

I expected the server to process only one request and reject the others because of the cooldown.

But that wasn't what happened.

A few seconds later, multiple verification emails started arriving in my inbox.

That's when I realized the one-minute restriction existed only in the browser. The backend wasn't enforcing the same rule, allowing all 12 requests to be processed simultaneously.

At that moment, it became clear that I had found a Race Condition in the email verification workflow.

An Unexpected Outcome

Although the finding was technically valid, it was considered out of scope under the bug bounty program's policy, so it wasn't eligible for a reward.

That was completely fine.

Bug bounty isn't only about earning rewards — it's also about improving your testing skills and understanding how real-world applications behave under unexpected conditions.

This finding taught me the importance of looking beyond the user interface and testing how the backend handles concurrent requests.

Why It Still Matters

Although this issue does not expose sensitive data, it can still impact the platform if abused.Why It Still Matters

Although this issue does not expose sensitive data, it can still impact the platform if abused.

Potential risks include:

• Increased email delivery costs and infrastructure usage.
• Additional load on email processing systems.
• Damage to email sender reputation, which may cause legitimate emails from the company to be classified as spam or have lower deliverability rates.
• This highlights how business logic vulnerabilities can affect service reliability, operational costs, and email deliverability even without direct data compromise.