Race Condition Hunter

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

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     # stateful ops not idempotent

JavaScript Patterns to Grep

// Single-use action buttons with client-side disable
button.disabled = true
$('#btn').prop('disabled', true)
// Optimistic UI updates (state set before server confirms)
setState({ used: true })
// Sequential async calls without locking
await useVoucher(); await deductBalance();

Tech Stack Signals

• Ruby on Rails without with_lock / lock! — ActiveRecord doesn't lock by default
• Node.js with async/await chains — non-atomic DB reads then writes
• PHP without SELECT ... FOR UPDATE — common in legacy codebases
• Microservices — inter-service calls introduce natural TOCTOU windows
• Redis counters without Lua scripts or INCR atomicity checks
• Message queues — idempotency keys often missing

• Enumerate one-time or limited-use actions — Map every endpoint that enforces a "once per user", "limited quantity", or "deduct balance" constraint. These are your primary targets.

• Understand the state machine — For each target action, identify: (a) what state is read, (b) what state is written, (c) what validation sits between read and write. The gap between read and write is your window.

• Capture a clean baseline request — Perform the action once legitimately with Burp Suite intercepting. Confirm you get the expected single-use behavior (e.g., coupon marked used, vote counted once).

• Set up parallel request tooling — Use one of:

• Execute the race — Send 10–50 identical requests simultaneously. Key technique: pre-connect and buffer all requests, release the final byte of all simultaneously (single-packet attack when HTTP/2 is available).

• Analyze responses — Look for:

• Verify the effect — Check the actual state: Was the credit applied twice? Did the vote count increment multiple times? Is the coupon still marked unused despite two successes?

• Determine exploitability window — Re-run with decreasing parallelism (5 requests, 3 requests, 2 requests) to understand how tight the window is and reliability of exploitation.

• Test across account types — Sometimes the race only works for new accounts, specific subscription tiers, or under specific server load. Test varied conditions.

• Document reproducibility — Record exact timing, number of parallel requests needed, and success rate across 5 independent attempts before reporting.

Turbo Intruder — Basic Parallel Race

# turbo_intruder_race.py
def queueRequests(target, wordlists):
    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=1,
                           engine=Engine.BURP2)  # HTTP/2 single-packet
    for i in range(20):
        engine.queue(target.req, gate='race1')
    engine.openGate('race1')
def handleResponse(req, interesting):     if '200' in req.status:         table.add(req)

curl — Parallel Requests (bash)

# Fire 15 simultaneous vote/redeem requests
for i in $(seq 1 15); do
  curl -s -o /dev/null -w "%{http_code}\n" \
    -X POST "https://target.com/api/vote" \
    -H "Cookie: session=YOUR_SESSION" \
    -H "Content-Type: application/json" \
    -d '{"report_id": "12345", "vote": "up"}' &
done
wait

Python asyncio Race

import asyncio, aiohttp
async def race_request(session, url, payload, headers):     async with session.post(url, json=payload, headers=headers) as r:         return await r.text()
async def main():     url = "https://target.com/redeem"     payload = {"code": "GIFT50"}     headers = {"Cookie": "session=XXXXX"}          async with aiohttp.ClientSession() as session:         tasks = [race_request(session, url, payload, headers) for _ in range(20)]         results = await asyncio.gather(*tasks)          for r in results:         print(r[:100])  # print first 100 chars of each response
asyncio.run(main())

Grep Patterns for Source Code Auditing

# Look for read-then-write without locking
grep -rn "find_by\|where.*first" --include="*.rb" | grep -v "lock"
grep -rn "SELECT.*WHERE" --include="*.php" | grep -v "FOR UPDATE"
# JavaScript async without atomicity grep -rn "await.*get\|await.*find" --include="*.js" -A2 | grep "await.*update\|await.*save"
# Python Django ORM without select_for_update grep -rn "\.get(\|\.filter(" --include="*.py" | grep -v "select_for_update"

HTTP/2 Single-Packet Check

# Verify target supports HTTP/2 (prerequisite for single-packet attack)
curl -sI --http2 https://target.com | grep -i "HTTP/2\|h2"

• Check-Then-Act without atomic operations — Developer reads state (if voucher.used == false), then writes state (voucher.update(used: true)) in two separate database operations. Any thread can read the same "unused" state before either writes.

• Missing database-level locking — Using ORM methods like find or filter instead of SELECT ... FOR UPDATE. The fix is one line but developers don't think about concurrency.

• Optimistic concurrency without version checking — Systems increment counters or mark records without checking if the record changed since it was read.

• Microservice TOCTOU — Service A validates eligibility, Service B executes the action. No shared atomic transaction spans both services.

• Client-side "protection" — Developers disable the button in JavaScript after first click, assuming that prevents duplicate submissions. Server-side logic is never hardened.

• Counter increments outside transactions — votes_count += 1; save() instead of an atomic SQL UPDATE SET votes = votes + 1 WHERE id = ?.

• Async background jobs — Eligibility checked synchronously, fulfillment done asynchronously. A second request passes the check before the first job completes.

• Caching without invalidation — Cached "has user voted?" check returns stale false during a cache miss window when the first write hasn't propagated yet.

What Defenders Implement (and How to Bypass)

Defense: Per-user rate limiting

• Bypass: Rate limits are checked before the action executes. Send requests simultaneously — all pass the rate-limit check before any is counted.

• Bypass: If the server generates or reuses the token, try sending parallel requests without the token. Or check if the uniqueness check itself has a race window.

• Bypass: The constraint catches duplicates after the race. The first two may both succeed before DB enforces. Look for partial fulfillment — sometimes one succeeds and one errors but both are honored.

• Bypass: Pre-stage all requests with valid tokens. Use single-packet HTTP/2 to release all in one TCP frame — server processes them in the same scheduler slot.

• Bypass: Multiple queues (or multiple workers consuming the same queue) can pick up duplicate messages. Test by overwhelming the queue during the window.

• Bypass: Distributed systems running multiple app servers don't share in-process locks. Send requests to the same endpoint via different CDN nodes or load-balanced servers.

• Bypass: The check and the update are separate. The check passes for both racing requests before either update completes. Only an atomic UPDATE ... WHERE used=false RETURNING id truly prevents this.

Before writing the report, confirm all three:

• What can the attacker DO right now?

• What does the victim LOSE?

• Can it be reproduced in 10 minutes from scratch?

Scenario 1: Social Platform Vote Manipulation

Scenario 2: Major Social Network — Duplicate Promotional Actions

Scenario 3: Cloud Infrastructure Provider — Resource Limit Bypass

The following real, verified bug-bounty / coordinated-disclosure cases extend this skill. Four cases (#4, #11, #12, plus the bonus reference) use the modern HTTP/2 single-packet attack technique (Kettle DEF CON 31, 2023; Flatt Security expansion 2024) — the technique that makes most modern race exploits viable today.

• GitLab — CVE-2022-4037 email-verification race (Kettle DEF CON 31 case study) ([NVD](https://nvd.nist.gov/vuln/detail/CVE-2022-4037) · [PortSwigger Research](https://portswigger.net/research/smashing-the-state-machine))

• Worldcoin (Tools for Humanity) — World ID action-verification race ([Medium writeup](https://medium.com/@gonzo-hacks/the-fast-and-the-curious-finding-a-race-condition-in-worldcoin-621c89bfbd61))

• Stripe — Promotion code redeemed past limit ([H1 #1717650](https://hackerone.com/reports/1717650))

• Stripe — Fee discounts redeemed many times ([H1 #1849626](https://hackerone.com/reports/1849626))

• Reverb.com — Gift card multi-redemption ([H1 #759247](https://hackerone.com/reports/759247))

• Cosmos / Starport faucet — Double-mint race ([H1 #1438052](https://hackerone.com/reports/1438052))

• InnoGames — Email-activation race → unlimited diamonds ([H1 #509629](https://hackerone.com/reports/509629))

• RyotaK / Flatt Security — "First Sequence Sync" PIN-bruteforce (10,000-req single-packet expansion) ([Flatt Security Research](https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/))

• nopCommerce — CVE-2024-58248 gift-card double-redemption ([NVD](https://nvd.nist.gov/vuln/detail/CVE-2024-58248))

The single-packet attack is the most important race-condition technique published since 2020. It collapses the race window from "tens of milliseconds with TCP-handshake jitter" to "the time the server's worker pool takes to dispatch N pre-buffered requests" — typically under 1 ms for the entire batch. This is what makes modern race exploits viable against rate-limited, distributed, load-balanced backends that previously seemed un-race-able.

Original research: James Kettle, PortSwigger — "Smashing the State Machine" (DEF CON 31, August 2023) [portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine). 2024 extension: RyotaK / Flatt Security — "Beyond the Limit: Expanding Single-Packet Race Condition with First Sequence Sync" [flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/](https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/).

Why it works — architecture

A race exploit fails for two reasons that look like the same problem but aren't:

• Network jitter — N requests sent sequentially over the same TCP connection arrive at the server with 0.5–5 ms spread, depending on RTT and congestion.
• Server-side dispatch ordering — even if all N requests arrive in the same millisecond, the worker pool may serialise them via a load balancer or accept-queue.

• HTTP/2 multiplexes N requests over ONE TCP connection as ONE TLS record per request batch.
• TLS records can carry multiple HTTP/2 HEADERS frames, and each HEADERS frame can be the last frame of a separate stream.

For (2) — server-side dispatch ordering — Kettle showed that modern backends (Node.js, Go, async Python) dispatch concurrently within microseconds when handed a packet of N pre-parsed requests. Older blocking backends (default Apache prefork, single-threaded PHP-FPM) serialise even with single-packet delivery; for those, the technique helps less but still wins over TCP-stream sequencing.

Last-byte-sync technique

The exact mechanic Kettle documented:

• Open one HTTP/2 connection. Negotiate TLS, send the SETTINGS frame, accept the server's.
• For each of N requests, send its HEADERS frame with the END_HEADERS flag and a DATA frame containing all but the last byte of the body. Do NOT set END_STREAM yet.
• The server cannot dispatch the request because END_STREAM hasn't fired — it's waiting for one more byte.
• Repeat (2) for all N requests on the same connection. Each is now buffered at the server, parsed up to "almost done".
• In a single TCP write, send N tiny DATA frames each carrying 1 byte with END_STREAM set. TCP coalesces them into one outbound segment. The server's HTTP/2 parser sees END_STREAM on all N streams in the same scheduler tick.
• Server dispatches N requests to N workers in microseconds.

Wireshark validation

To confirm your attack tool is genuinely producing one-packet sync (vs accidentally fragmenting):

• Capture the loopback or your egress interface during the attack: sudo tcpdump -i lo0 -w race.pcap port 443 (or interface 0).
• Open in Wireshark, filter tls and tcp.port == 443.
• Find the TLS record containing the END_STREAM flush. It should contain N H2 DATA frames with END_STREAM set, in one TLS record, in one TCP segment.
• If you see N TLS records or N TCP segments, your tool is sequencing. The race window is your inter-segment gap — typically too wide.

h2.0 single-frame vs h2.cl multi-frame race

Two variants depending on what protocol the target speaks:

• h2.0 single-frame (the standard Kettle attack): pure HTTP/2 end-to-end. N requests in one TLS record. Works against any modern HTTPS-fronted target where the front-end advertises h2 in ALPN. Default approach.
• h2.cl multi-frame: front-end speaks HTTP/2 to the client, downgrades to HTTP/1.1 to the back-end. Smuggling-adjacent — you craft an HTTP/2 request whose Content-Length confuses the front-end into emitting two HTTP/1.1 requests to the back-end on the same connection. Pairs with HTTP request smuggling (see hunt-http-smuggling). Useful when single-packet HTTP/2 is filtered at the front-end but the back-end is reachable in HTTP/1.1.

Race-window estimation methodology

Before firing the attack, estimate the race window. This determines whether you need single-packet at all, and how many concurrent requests to send.

• Issue a single request to the target endpoint. Capture the response time on the wire: T_single.
• Issue two sequential requests. Capture both response times: T_seq1, T_seq2.
• Issue two concurrent requests over the same connection (via HTTP/2 multiplex or HTTP/1.1 pipeline). Capture both: T_par1, T_par2.
• If T_par1 ≈ T_par2 ≈ T_single, the server handles both in parallel — race window is min(T_par1, T_par2), single-packet helps a lot.
• If T_par2 ≈ T_par1 + T_single, the server serialises — race window is whatever happens between sequential workers; single-packet helps less but still wins over TCP jitter.
• For PIN / OTP / coupon-redemption endpoints, expect T_single to be 10–100 ms (DB query latency). The race window inside the server is typically < 1 ms (the gap between SELECT and UPDATE on the same row).
• N rule of thumb: start with N = 30 concurrent requests for single-packet h2. Increase to 100+ if the target's T_single is < 10 ms (very fast endpoint = larger pre-buffer needed to overflow the worker pool). Up to 10,000 with Flatt's first-sequence-sync extension (see below).

Single-connection-multi-stream vs Multi-connection-single-stream

A decision tree for picking the right shape:

• Single connection, N streams (default Kettle / Turbo Intruder BURP2 engine): N concurrent HTTP/2 streams on one TCP connection. Use when: target speaks HTTP/2; request body fits in MTU (~1400 bytes after TLS overhead); you need N ≤ ~30.
• Multiple connections, one stream each (older parallel HTTP/1.1): N TCP connections, one request per connection. Use when: target doesn't speak HTTP/2 OR the request body is large (> MTU). Race window widens significantly (5–50 ms TCP-handshake spread) — only viable on slow servers.
• Multiple connections, multiple streams (Flatt's first-sequence-sync, 2024): N TCP connections each carrying M streams. Total = N×M requests. Uses synchronized TCP first-sequence numbers across multiple connections to land all packets at the server in the same processing window. Use when: you need N > 30 (e.g., brute-forcing a 6-digit PIN within a 5-attempt rate-limit window — Flatt demonstrated 10,000 requests in 166 ms by splitting across IP fragments with synchronized SEQ numbers).

Turbo Intruder Engine.BURP2 template — explained

def queueRequests(target, wordlists):
    # 1. Engine.BURP2 = HTTP/2 single-packet engine; provides the last-byte-sync primitive.
    engine = RequestEngine(
        endpoint=target.endpoint,
        concurrentConnections=1,          # 2. One TCP connection, multiplexing all streams.
        requestsPerConnection=100,        # 3. Up to 100 concurrent H2 streams. >30 needs Flatt-extension.
        engine=Engine.BURP2,              # 4. THE critical line — selects the single-packet engine.
        pipeline=False,                   # 5. Pipelining is for HTTP/1.1; irrelevant on H2.
    )
# 6. Build N requests. Each is identical here — racing the same endpoint.     #    For PIN brute-force, vary the body across requests.     for i in range(30):         engine.queue(target.req)
# 7. openGate(...).complete(...) is the API call that performs last-byte-sync:     #    - Buffer all 30 requests up to "last byte not sent"     #    - Release all final bytes in a single TCP write     #    - openGate returns immediately; complete waits for all responses.     engine.openGate("race1")     engine.complete(timeout=10)

The Engine.BURP2 import does the heavy lifting. Behind the scenes:

• Each engine.queue(req) adds a HEADERS frame to the connection's send buffer but withholds the last DATA frame byte.
• openGate("race1") blocks until all 30 are buffered, then issues a single socket.send(...) containing 30 × 1-byte DATA frames with END_STREAM. All 30 cross the wire in one IP packet (assuming < MTU).
• complete(timeout=10) collects responses and times.

Flatt's first-sequence-sync extension (when N > 30 is needed)

Kettle's original single-packet caps at roughly N=30 due to MTU + TLS record limits. Flatt Security's RyotaK published the extension in August 2024:

• Take advantage of IP fragmentation: a single "logical" packet at the IP layer can be split across multiple physical IP fragments.
• Force synchronized TCP SEQ numbers across multiple connections by completing the TLS handshakes in lockstep and aligning the SYN/SYN-ACK timing.
• Result: 10,000 concurrent requests delivered to the server in 166 ms, all landing inside a rate-limit window that the server thought was atomic.

Implementation: [flatt.tech/research/posts/beyond-the-limit-...](https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/) includes a working PoC.

Operator playbook (when to reach for what)

Anti-patterns

• Don't claim "race condition" from observing two near-simultaneous successes in Burp Repeater "Send group in parallel" mode — that mode pipelines over HTTP/1.1 with millisecond-spread, not single-packet. Triagers know this and downgrade.
• Don't submit without Wireshark confirmation for high-value race claims. The deliverable that pays best: PoC video showing Turbo Intruder firing + Wireshark capture showing all N END_STREAM frames in one TCP segment + N successful responses that should have been mutually exclusive.
• Don't use single-packet against endpoints that genuinely don't race (e.g., endpoints with row-level locks and transactions). The window estimation step exists to filter these out before you spend 2 hours building the PoC.

Cross-references

• hunt-http-smuggling — h2.cl multi-frame variant
• hunt-mfa-bypass — OTP rate-limit window single-packet bypass (Flatt PIN-bruteforce class)
• hunt-business-logic — coupon / wallet / promo state-machine races where single-packet is the enabling primitive
• Disclosed Report Citations above — citations #4, #11, #12 are the canonical single-packet exemplars (GitLab/Devise CVE-2022-4037, Flatt 10k-req PIN brute-force, nopCommerce CVE-2024-58248)

• hunt-business-logic — Race conditions are the "concurrency arm" of every business-logic state machine. Chain primitive: business logic (coupon/promo) + race-condition single-packet attack → coupon redeemed N times → direct financial loss.
• hunt-mfa-bypass — OTP-expiry windows and replay protection are classic race targets. Chain primitive: race + MFA-validate endpoint → bypass OTP expiry by submitting N concurrent validations within the validity window.
• hunt-ato — Race conditions on password reset, email change, and account creation enable persistent ATO. Chain primitive: race on email-change endpoint + atomic-update missing → swap victim email + read reset token before user notice.
• hunt-api-misconfig — Wallet/balance/credit endpoints without atomic UPDATE are double-spend candidates. Chain primitive: race + atomic-update missing → double-spend balance → withdraw N× user balance.
• security-arsenal — Load the Turbo Intruder single-packet template, h2.cl smuggling for atomic submit, and curl --next parallel multi-request patterns.
• triage-validation — Apply the Statistical-Sampling gate: a single anomalous response is noise; require 1 successful + N duplicate / over-quota / stale-state demonstrations with response screenshots before reporting.