Introduction

Most people think financial bugs need complex logic, deep crypto flaws, or advanced exploitation techniques.

But sometimes… all it takes is speed.

While reading older HackerOne reports, I found a fascinating vulnerability reported by cablej (Report ID #429026). The bug was not in payments, not in banking APIs, and not in authentication.

It was in a retest confirmation feature.

By sending the same request multiple times at the exact same moment, the system paid the researcher more than once for a single retest.

  • No alerts.
  • No warnings.
  • No immediate detection.

And after two weeks, real money appeared in the bank account.

HackerOne paid $2,500 for this report — and deservedly so.

Let's break it down step by step in very simple language.

Report Overview:

  • Report ID: 429026
  • Reported By: cablej
  • Bounty Paid: $2,500
  • Vulnerability Type: Race Condition
  • Affected Feature: Retest Confirmation & Payments

What Is a Race Condition? (Simple Explanation)

A race condition happens when:

The server processes multiple requests at the same time, without properly checking if the action was already completed.

In short:

  • The system assumes only one request will arrive
  • The attacker sends many requests together
  • The server gets confused
  • The same action happens multiple times

Think of it like this:

  • You press the "Pay" button once
  • The system gives money
  • You press it 5 times at the same moment
  • The system pays 5 times

That's exactly what happened here.

The Vulnerable Feature: Retest Payments

HackerOne allows researchers to:

  • Request retests
  • Confirm retests
  • Receive payment for successful retests

The payment is triggered when the researcher confirms the retest.

The mistake:

  • HackerOne did not properly lock the payment action
  • It trusted that the confirmation would be sent only once

Step-by-Step Exploitation

Step 1: Receive Retest Email

The researcher first received a retest request email from HackerOne.

This email contained a link that triggers the retest confirmation request.

Step 2: Intercept the Request

Using Burp Suite, the researcher:

  • Clicked the retest confirmation link
  • Intercepted the HTTP request
  • Right-clicked it
  • Selected "Copy as curl command"

Now the request could be replayed from the command line.

Step 3: Send Multiple Requests at Once

Here is the clever part

Instead of sending the request once, the researcher ran:

(request) & (request) & (request) & (request) & (request)

This sends multiple confirmation requests simultaneously.

  • No delay.
  • No waiting.
  • All at the same time.

Step 4: Check Payments Page

After sending the requests, the researcher visited:

https://hackerone.com/settings/bounties

At the bottom of the page, under Retest Payments, the same payment appeared multiple times.

This already confirmed the bug visually.

Step 5: Wait (The Scary Part)

Nothing happened immediately.

  • No error.
  • No warning.
  • No rollback.

After two weeks, a message arrived from HackerOne staff.

Then the researcher checked the bank account.

None

$500 was paid multiple times

This proved the race condition worked in real life, not just UI-level.

Impact Analysis

This bug was extremely dangerous.

Why?

  • Direct financial loss
  • No immediate detection
  • Exploitation could remain hidden for weeks
  • Could be repeated multiple times
  • Payment systems were affected

An attacker could:

  • Trigger multiple retests
  • Confirm them rapidly
  • Collect money quietly
  • Repeat the process again later

That's why HackerOne treated this as high-impact.

Root Cause

The backend failed to:

  • Lock the retest confirmation process
  • Ensure idempotency (only one payment per retest)
  • Check if the retest was already paid
  • Reject duplicate simultaneous requests

In short:

No server-side protection against concurrency

How This Could Have Been Prevented

HackerOne could have prevented this by:

  • Using database locks
  • Adding a "paid" flag check
  • Rejecting duplicate confirmations
  • Using atomic transactions
  • Enforcing one-time tokens

These are basic backend protections for money-related actions.

How Bug Hunters Can Find Similar Bugs

Look for features involving:

  • Payments
  • Rewards
  • Credits
  • Wallets
  • Refunds
  • Coupons
  • Retests
  • Subscriptions

Then test:

  • Sending the same request in parallel
  • Using & in curl
  • Using Burp Intruder (Pitchfork / Turbo Intruder)
  • Sending rapid duplicate requests

If money or credits are involved always test race conditions.

Final Thoughts

This report proves one important lesson:

You don't always need complex payloads to find serious bugs.

Sometimes

  • One request
  • Sent faster
  • Than the server expects

…is enough to steal real money.

That's why race conditions are:

  • Hard to detect
  • Easy to miss
  • Extremely dangerous

And that's exactly why this bug earned $2,500.