race-condition

Tests web applications for race conditions and TOCTOU flaws using parallel HTTP request techniques.

Updated Jun 5, 2026
One-click install
npx skills add https://github.com/lNwNl/Praxis --skill race-condition-lnwnl
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: race-condition
Source: https://github.com/lNwNl/Praxis/tree/main/skills/race-condition
Command: npx skills add https://github.com/lNwNl/Praxis --skill race-condition-lnwnl

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Web applications often fail to enforce atomicity between state checks and state updates, allowing duplicate redemptions, double-spends, rate-limit bypasses, and verification forgery. This Skill provides a structured playbook for detecting and confirming these concurrency vulnerabilities during authorized security testing. ## Core Features & Use Cases - Attack Pattern Library: Covers limit-overrun (coupon reuse, double-spend, inventory oversell, referral abuse), rate-limit bypass via simultaneity, and multi-step pipeline races with concrete request examples and success signals. - Transport Synchronization Techniques: Documents HTTP/1.1 last-byte synchronization, HTTP/2 single-packet attacks with TCP Nagle coalescing mechanics, and Turbo Intruder gate templates for tightly timed parallel request bursts. - Database Isolation Analysis: Maps READ COMMITTED, REPEATABLE READ, and SERIALIZABLE isolation levels to exploitable phenomena with SQL examples and an audit checklist for locks, transactions, and UNIQUE constraints. - Use Case: While testing an e-commerce target, you capture the apply-coupon request, fire 30 gated copies via Turbo Intruder, observe multiple 200 responses and a multiplied discount, then confirm the missing UNIQUE constraint as the root cause. ## Quick Start Test the coupon redemption endpoint on my authorized target for race conditions by sending parallel requests and checking for duplicate success responses.

Frequently Asked Questions about race-condition

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test a web application for race condition vulnerabilities?▼

Capture a state-changing request in a proxy, then send 20-100 copies as simultaneously as your tooling allows using Turbo Intruder gates or Burp's single-packet attack. Confirm the flaw by observing duplicate success responses, duplicate database rows, or an inconsistent final balance.

What is the difference between HTTP/2 single-packet and HTTP/1.1 last-byte sync attacks?▼

HTTP/2 single-packet multiplexes streams into one TCP segment, achieving sub-100-microsecond server dispatch gaps with a single connection. HTTP/1.1 last-byte sync holds the final byte across N connections and releases together, but suffers 1-5 ms network jitter per connection.

Which endpoints are most likely vulnerable to race conditions?▼

Prioritize one-time operations where check and update are not atomic: coupon redemption, balance transfers, inventory deduction, referral claims, and email or MFA verification. Any POST that should succeed only once per user is a candidate.

How do database isolation levels affect race condition exploitation?▼

READ COMMITTED allows classic TOCTOU double-spends when SELECT and UPDATE lack FOR UPDATE locking. REPEATABLE READ permits phantom inserts where both threads see zero existing claims. UNIQUE constraints defeat these attacks regardless of isolation level.

What tools can send synchronized parallel HTTP requests for race testing?▼

Turbo Intruder provides gate-based release with threaded engines inside Burp Suite. Burp Repeater supports send-group single-packet attacks over HTTP/2, and h2spacex offers low-level HTTP/2 frame control for custom single-packet bursts.

When should I use business logic testing instead of race condition testing?▼

Use race condition testing when the flaw involves concurrency, timing windows, or non-atomic check-then-act sequences. If the issue concerns pricing rules, workflow order, or coupon policy logic rather than simultaneity, a business-logic-vulnerabilities approach fits better.