Race Condition
Stress one-time redeem, balance, and inventory endpoints with concurrent HTTP to find TOCTOU and CWE-362 gaps before launch or payout bugs hit production.
Overview
Race-condition is an agent skill most often used in Ship (also Build backend hardening, Operate iterate) that tests TOCTOU and concurrent HTTP abuse on one-time and balance-like web operations under authorized scope.
Install
npx skills add https://github.com/yaklang/hack-skills --skill race-conditionWhat is this skill?
- Priority table for one-time redeem, balance/quota deduction, referral bonus, and credential-change races
- Frames races as authorization and state-integrity failures from non-atomic read-then-write
- Combines HTTP/1.1 last-byte sync, HTTP/2 single-packet, and Turbo Intruder gate patterns
- Application evidence: duplicate successes, inconsistent balances, duplicate ledger rows
- Cross-load business-logic-vulnerabilities for coupons, inventory, and one-time rewards
- 4-row priority table for operation classes (redeem, balance, referral, credential changes)
- Explicit CWE-362 / synchronization-gap framing
Adoption & trust: 1.1k installs on skills.sh; 980 GitHub stars; 1/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your redeem, transfer, or stock endpoints look correct in single-threaded tests but may grant double benefits when many requests hit the same non-atomic check.
Who is it for?
Solos shipping fintech-lite, coupons, referrals, or inventory APIs who can run Burp Turbo Intruder or scripted parallel clients in staging.
Skip if: Unauthorized load attacks on third-party sites, or teams without a safe staging environment to hammer financial endpoints.
When should I use this skill?
Testing one-time operations, concurrent HTTP abuse, rate-limit bypass, Turbo Intruder gates, HTTP/2 single-packet attacks, and CWE-362-style synchronization gaps.
What do I get? / Deliverables
You document reproducible concurrent abuse with transport setup and duplicate-state evidence so backends can add locking, idempotency keys, or atomic updates.
- Repro steps with transport mode and concurrent request count
- Evidence of duplicate success or inconsistent server-side state
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Race testing is canonical pre-ship security for money-, coupon-, and quota-shaped flows solos often build themselves. Parallel transport abuse and duplicate-success evidence belong under security review, paired with business-logic skills when workflows involve coupons or inventory.
Where it fits
Hammer a staging coupon redeem endpoint with gated parallel requests before public launch.
Design purchase and reserve handlers with race tests in mind while implementing check-then-deduct SQL.
Reproduce user reports of double referral bonuses using HTTP/2 single-packet timing on production-like data.
How it compares
Concurrent authorization-state testing playbook, not a generic load-testing or rate-limit configuration skill.
Common Questions / FAQ
Who is race-condition for?
Indie builders and appsec-minded developers validating their own checkout, wallet, coupon, and signup-bonus flows under contract or internal scope.
When should I use race-condition?
At Ship security on one-time operations and quotas; during Build when designing idempotent purchase paths; in Operate when investigating duplicate ledger rows or inconsistent balances after launch.
Is race-condition safe to install?
It describes exploitative concurrency—use only with explicit permission and isolated staging; review the Security Audits panel on this Prism page before agent use.
SKILL.md
READMESKILL.md - Race Condition
# SKILL: Race Conditions — Testing & Exploitation Playbook > **AI LOAD INSTRUCTION**: Treat race conditions as **authorization/state integrity** issues: non-atomic read-then-write lets multiple requests observe stale state. Prioritize **one-time** or **balance-like** operations. Combine **parallel transport** (HTTP/1.1 last-byte sync, HTTP/2 single-packet, Turbo Intruder gates) with **application evidence** (duplicate success responses, inconsistent balances, duplicate ledger rows). **Authorized testing only.** Routing note: for business workflows, coupons, inventory, or one-time rewards, start with this skill and cross-load `business-logic-vulnerabilities`. --- ## 0. QUICK START — What to Test First Target endpoints where **check** and **update** are unlikely to be a single atomic database operation: | Priority | Operation class | Example paths / parameters | |----------|------------------|----------------------------| | 1 | One-time redeem / coupon / bonus | `redeem`, `apply_coupon`, `claim_reward`, `voucher` | | 2 | Balance / quota / stock deduction | `transfer`, `purchase`, `reserve`, `inventory` | | 3 | Invite / referral / signup bonus | `invite_accept`, `referral_claim` | | 4 | Password / email / MFA verification | `verify_token`, `confirm_email`, `reset_password` | | 5 | Idempotent-looking APIs without strong keys | `POST` that should succeed only once per user | **First moves (conceptual)**: 1. Capture the **state-changing** request in a proxy. 2. Send **20–100** copies **as simultaneously as your tooling allows**. 3. Classify outcome: **0/1 expected successes** vs **N successes** or **inconsistent final state**. --- ## 1. CORE CONCEPT ### 1.1 TOCTOU (Time-of-check to time-of-use) ``` Thread A Thread B | | +-- CHECK (resource OK) | | +-- CHECK (resource OK) ← both see "OK" +-- USE / UPDATE | | +-- USE / UPDATE ← duplicate effect ``` **TOCTOU** means the **decision** (check) and the **mutation** (use) are not one indivisible step. ### 1.2 Non-atomic read-then-write Typical vulnerable pseudo-flow: ```text balance = SELECT balance FROM accounts WHERE id = ? if balance >= amount: UPDATE accounts SET balance = balance - ? WHERE id = ? ``` Two concurrent requests can both pass the `if` before either `UPDATE` commits. ### 1.3 Database-level vs application-level locking gaps | Layer | What goes wrong | |-------|------------------| | **Application** | In-memory flag, cache, or session says "not used yet" while DB already updated — or the reverse. | | **ORM / service** | Two instances, no distributed lock; each thinks it owns the decision. | | **DB** | Missing `SELECT … FOR UPDATE`, wrong isolation level, or logic split across multiple statements without transaction. | | **API gateway** | Per-IP rate limit is **check-then-increment** — parallel burst passes duplicate checks. | **Hint**: `UNIQUE` constraints and **idempotency keys** often eliminate entire bug classes — test whether the app **enforces** them on the hot path. --- ## 2. ATTACK PATTERNS ### 2.1 Limit-overrun (double redeem / double claim) Send the **same** authenticated request many times in parallel: ```http POST /api/v1/rewards/claim HTTP/1.1 Host: target.example Authorization: Bearer <token> Content-Type: application/json {"reward_id":"welcome_bonus"} ``` **Success signal**: HTTP `200`/`201` more than once, duplicate ledger entries, or balance higher than policy allows. ### 2.2 Rate-limit bypass via simultaneity If limits are implemented as **counters checked per request** without atomic increment: ```http POST /api/v1/login HTT