Race conditions (RatRace)

Land many requests in the same instant to beat the gap between check and use — single-packet, last-byte, barrier, or GraphQL-batch sync, with calibration, capture-inject, and state-verify to turn a window into a confirmed catch. (Pro)

A race condition is the window between when an app checks something and when it acts on it: redeem a coupon twice, withdraw the same balance in parallel, beat a rate limit by arriving all at once. RatRace is Hugin's engine for landing many requests inside that window. It is a Pro feature (the read-only views — sessions, results, discovered endpoints — are reachable in Community; firing attacks needs Pro).

The sync engines

Each engine packs the burst onto the wire a different way. Pick one, or leave it on auto — RatRace routes a graphql/gql endpoint to GraphQL batch, an HTTPS target to last-byte, and a plain-HTTP target to barrier.

The burst size is concurrency (default 10, capped at 256) repeated over rounds (default 1). A real race converges in the tens, not the thousands.

Run it

1. Find a candidate

   An action that checks a limit then mutates state — a balance, a quota, a one-time token, an idempotency key. discover ranks a list of URLs by how race-prone they look (payment, coupon/referral, balance transfer, inventory, MFA, password-reset, subscription-downgrade and more); param-hunt ranks the parameters on a single endpoint.

2. Send it as a batch

   Take the request to RatRace, set the batch size, and fire with single-packet, last-byte, or auto. You can also send a single-packet batch straight from Repeater (Atomic Send) or Intruder.

3. Read the outcome

   Two successes where one was allowed is the bug. Check the resulting state, not just the responses — turn on calibration or state-verify (below) to make the catch unarguable.

Attack modes

Beyond a raw test, RatRace ships preset modes that shape the burst for a specific bug class. Each is a one-call wrapper over the same engines.

Protocol races

Two protocols get dedicated handlers with their own config, because the race lives in the protocol's own flow rather than a single request.

Read the verdict

Every round is classified into one signal; the strongest signal across all rounds is the session verdict.

• CLEAN_CATCH — a confirmed race. Divergent statuses with some succeeding, a database race error in a body, or a calibrated limit bypass.
• SILENT_SUCCESS — the burst changed server state with no error in sight, confirmed by state-verify. The double-spend receipt.
• LOGICAL_RACE — successful responses that disagree with each other, a sign the parallel requests diverged the logic.
• DIRTY_CATCH — a lead to chase, not yet proof. Includes the key case below.
• RATE_LIMITED — the target's guard held across the burst (most responses 429).
• FALSE_POSITIVE / NO_SIGNAL — nothing actionable this run.

Identical successes mean different things by method. On a safe method (GET/HEAD/OPTIONS) a burst of byte-identical 200s is a true negative (FALSE_POSITIVE). On POST/PUT/PATCH/DELETE the same burst is flagged DIRTY_CATCH — the side effect may have been applied N times (silent double-spend) — and RatRace points you at state-verify to confirm it.

The verdict is built from divergence signals across the burst:

Catch a limit bypass with calibration

This turns "the rate limit holds for one request but folds under concurrency" into a clean, defensible catch.

Enable calibrate and RatRace sends one non-concurrent request first, then the burst. If that single request is rejected — a 429, a one-time-use 409/403, a 4xx balance or precondition error — but two or more concurrent requests succeed, that is a per-request guard bypassed under load. It is reported as limit_bypass and promoted straight to CLEAN_CATCH, even when every winning response is byte-identical and the burst has no internal divergence.

Calibration is off by default: the baseline request is one real extra invocation, so only enable it where priming the endpoint once is safe.

Chain a multi-step race

Most real races need a setup step first — create the basket, mint the draft order, grab a fresh token. Configure a prerequisite request that runs once before the burst. It has two uses:

• Pure setup — create the resource the race targets, then race the next step (add-to-cart, then race checkout).
• Capture-and-inject — pull a value out of the prerequisite's JSON response by path (for example data.token) and thread it into every burst request: as a named header, optionally templated (Bearer {{CAPTURE}}), and/or by substituting the {{CAPTURE}} marker anywhere in the burst's URL, body, or header values.

A value captured from the prerequisite (often a fresh bearer) is never written into the saved session.

Prove the double-spend with state-verify

Responses lie; state is proof. A double-spend often returns N identical 200s and nothing else. Point state-verify at a read endpoint — a wallet balance, an order count — to fetch the state before and after the burst. Narrow the comparison to the field that matters with a JSON path (data.wallet.balance) so a volatile timestamp or CSRF token does not produce noise.

A confirmed change on the targeted field upgrades the verdict to SILENT_SUCCESS — the before/after diff you put in the report.

Tune the window

When a burst comes back empty, the timing is usually the problem, not the target.

Race with auth: drive it from the API or agent

The GUI Send to RatRace prefills the URL, method, and body of the flow — but not its Authorization or Cookie headers, so a race launched that way runs unauthenticated. For an authenticated race, set the headers yourself by driving RatRace from the API or an MCP agent, where the full header set goes on the wire.

Last updated 2026-06-17.