competition-race-condition-state-drift

Reproduce and prove race conditions causing state drift in CTF sandbox targets.

7|4|Updated Jun 22, 2026
One-click install
npx skills add https://github.com/dbx0/skills --skill competition-race-condition-state-drift-dbx0
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: competition-race-condition-state-drift
Source: https://github.com/dbx0/skills/tree/main/skills/web-appsec/initial-access/competition-race-condition-state-drift
Command: npx skills add https://github.com/dbx0/skills --skill competition-race-condition-state-drift-dbx0

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Timing-sensitive bugs like race windows, lock gaps, and idempotency failures are hard to reproduce and prove decisively. This Skill provides a structured CTF workflow for isolating concurrent state corruption, duplicate actions, and stale-read effects into a minimal replayable sequence. ## Core Features & Use Cases - Mutable Boundary Mapping: Identify rows, cache keys, queue payloads, counters, and session fields, then record transaction scope, lock behavior, retry logic, and idempotency keys. - Deterministic Race Reproduction: Build controlled concurrent inputs with fixed delays, duplicate requests, or reordered worker execution, comparing baseline and racing runs with only one variable changed. - Decisive Chain Reduction: Compress findings into a minimal chain of request ordering, stale check or lock gap, conflicting writes, and resulting capability or artifact. - Use Case: During a CTF challenge, you suspect a balance-transfer endpoint accepts duplicate concurrent requests. Use this Skill to map the read-check-write boundary, replay a two-request race, and prove final balance drift from a clean reset. ## Quick Start Ask the agent to reproduce a race condition on the target endpoint by capturing one baseline run and one concurrent run, then proving the final state drift with a minimal replayable sequence.

Frequently Asked Questions about competition-race-condition-state-drift

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

FAQPage Schema
How do I reproduce a race condition in a web application?

Identify the mutable state first, such as rows, cache keys, or counters, then send a minimal concurrent sequence with controlled timing. Capture one baseline run and one racing run with only one variable changed, and prove the final state drift from a clean reset.

How to test for idempotency failures with duplicate requests?

Send duplicate requests with identical payloads and compare accepted versus rejected paths. Track whether idempotency keys, lock behavior, or retry logic prevent the second mutation, and record which condition flips when ordering changes.

What evidence proves a race condition caused state drift?

Keep the mutable key with its initial and final values, timestamped request ordering with delays and retries, and the resulting effect such as duplicated actions or balance drift. A minimal replayable concurrent sequence proving drift from a clean reset is the decisive artifact.

When should I use this skill instead of the CTF orchestrator?

Use it only after the ctf-sandbox-orchestrator has established sandbox assumptions, node ownership, and evidence priorities. It is a downstream specialization for cases where decisive behavior depends on request timing, async ordering, lock gaps, or stale state.

Why do race condition tests produce unreliable results?

Unreliable results come from noisy stress tests without a minimal deterministic sequence, mixing several mutable keys without isolating the driving one, or reporting timing sensitivity without final-state parity proof. Fix this by controlling delays and changing only one variable per run.