hunt-race-condition

> **⚠️ AUTHORIZED USE ONLY**

> This skill is for educational purposes or authorized security assessments only.

> You must have explicit, written permission from the system owner before using this tool.

> Misuse of this tool is illegal and strictly prohibited.

> **Mandatory confirmation gate**

> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:

> 1. Ask the user to state the exact target URL, IP, account, or resource.

> 2. Ask the user to confirm written authorization and the permitted scope.

> 3. Show the exact command(s) and explain their expected effect.

> 4. Wait for explicit confirmation in the current conversation.

>

> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

Firing a race — two primitives (tooling-agnostic)

Winning a race needs requests that arrive in the *same* narrow window — sequential sends never

work. Use a single-packet / synchronized-send tool: **Burp Repeater** "Send group in parallel"

(HTTP/2 single-packet attack), **Turbo Intruder** (`engine=Engine.BURP2`, `gate` sync), or any

client that can flush N requests simultaneously. Two shapes:

- **Identical-copies race** — fire N IDENTICAL copies of one request at once (limit-overrun:

double-spend a coupon/gift-card, exceed a one-per-user quota). Success = ≥2 of the N return 2xx.

- **Different-requests race (partial construction)** — fire a LIST of DIFFERENT requests in one

synchronized window, repeated over several rounds. For register-then-confirm / TOCTOU races

where the object exists in a usable state mid-creation. Example (email-verification bypass —

register an arbitrary email, then confirm it through the construction window with a blank token):

```

Request A: POST /register body: csrf=<csrf>&username=hacker&email=anything@exploit.net&password=pw

Request B: GET /confirm params: token= (empty)

Fire A and B together, repeat ~20 rounds.

```

Get a fresh CSRF from `GET /register` first, then fire the batch. After it succeeds, log in as the

new account and perform the objective (e.g. a state-changing admin action such as deleting a user).

The blank-token confirm wins during the window where the user row exists but its verification

token isn't set yet.

Crown Jewel Targets

Race conditions are high-severity findings because they break financial, access control, and integrity assumptions that defenders rarely stress-test. Highest payouts come from:

- **Monetary/credit systems** — double-spending gift cards, coupons, referral bonuses, promotional credits, wallet balances

- **Vote/reputation manipulation** — upvoting the same content multiple times, gaming leaderboards or trending algorithms

- **Account limits bypass** — exceeding free-tier quotas, bypassing "one per user" restrictions on invites, trial activations, or API key generation

- **Privilege escalation** — racing role assignment or permission checks during user creation/upgrade flows

- **Deletion bypass** — reading or exfiltrating data during a narrow window between "marked for deletion" and "actually deleted"

- **Payment flows** — charging a card once but receiving multiple fulfillments

**Best-paying asset types:** Fintech apps, SaaS platforms with credit/subscription models, social platforms with reputation systems, e-commerce checkout flows, OAuth/SSO token endpoints.

---

Attack Surface Signals

URL Patterns

/vote, /upvote, /like, /favorite
/redeem, /apply-coupon, /use-code, /claim
/purchase, /checkout, /confirm-order, /pay
/transfer, /withdraw, /send-money
/invite, /referral, /accept-invite
/upgrade, /activate, /trial
/delete, /deactivate, /cancel
/follow, /subscribe

Response Headers That Signal Race-Prone Backends

X-RateLimit-*        # rate limiting exists, but may not be atomic
X-Request-Id         # each request independently tracked
No Cache-Control