# Race condition in performing retest allows duplicated payments

Race condition in HackerOne retest confirmation endpoint let concurrent requests trigger duplicate retest payments, paying the researcher multiple times for one retest.

- Payout: hidden
- Severity: medium
- Program: HackerOne
- Found by: cablej
- Disclosed: 2018-12-27
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/429026
- Library page: https://bugbountylibrary.com/r/h1%3A429026
- Tags: area:web domain:web impact:funds-loss kind:bounty platform:hackerone sev:medium technique:race-window vuln:business-logic vuln:race-condition

**Target:** Retest confirmation endpoint on hackerone.com
**Root cause:** The retest confirmation handler lacked synchronization/idempotency, so concurrent identical requests each processed a payment for the same retest.
**Steps:**
1. Receive a retest request email from HackerOne.
2. Intercept the retest request in Burp Suite and use `Copy as curl command`.
3. Run the request concurrently on the command line as `(request) & (request) & ...` (tested with 5 parallel requests).
4. Check https://hackerone.com/settings/bounties; repeated entries appear under `Retest payments`.
5. Wait; a $500 payment was received confirming the duplicate payout.
**How found:** Noticed retest confirmation is a state-changing action and hypothesized parallel duplicate requests would each be paid; tested with 5 concurrent curl requests.
**Exploitation:** Fire the same retest-confirmation request N times in parallel so each passes the check before any records the payment, yielding N retest payouts for one retest.
**Escalation:** Repeat across many retest requests to multiply stolen payouts.
**Insight:** Any endpoint that triggers a payout on a one-time action (retest confirm, reward approval) is a race candidate: replay the exact intercepted request in parallel and check the payments ledger for duplicate entries.