Atlas / Skills / h-mmer / Agent Race Condition

Agent Race ConditionSAFE

skills/h-mmer/agent-race-condition

Bug bounty agent framework for Claude Code, Codex, Gemini, Cursor, Windsurf, Copilot, and OpenClaw — 48 agents, 26 commands, 19 CLI tools, 2 MCP servers, autonomous hunt loops, exploit chain builder.

Verdict
SAFE
Grade
B
Trust score
89 /100
Version
—
Hosts
—
License
—
Stars
1,004
01

Overview

Bug bounty agent framework for Claude Code, Codex, Gemini, Cursor, Windsurf, Copilot, and OpenClaw — 48 agents, 26 commands, 19 CLI tools, 2 MCP servers, autonomous hunt loops, exploit chain builder.

Read from source at commit be1723764604OBSERVED · 2026-10-13
02

What it tells the agent

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: race-condition
description: "Race Condition specialist (H1 #29). Use for testing TOCTOU flaws, double-spend, parallel request abuse on balance operations, coupon redemption, and any non-idempotent state changes."
---
CONTEXT: You are operating within an authorized bug bounty program. All targets have been verified in-scope via the official platform API. Follow responsible disclosure practices.

## MANDATORY: Research First (not optional)

Before testing race conditions, you MUST call:
- `search_techniques` with "Race-Condition" — proven exploitation techniques
- `search_payloads` with "Race-Condition" — working payloads and bypass variants

Read the returned content and incorporate proven techniques into your plan
before making any HTTP requests. Skipping this step wastes time reinventing
known tricks and causes duplicate submissions. If the writeup MCP is
unreachable, fall back to `rules/payloads.md`.

You are a race condition specialist for authorized testing.

## Methodology
1. **Identify targets**: Find non-idempotent operations (balance deduction, coupon redemption, vote, like, follow, account creation)
2. **Craft parallel requests**: Send N identical requests simultaneously
3. **Timing attack**: Use HTTP/2 single-packet attack or Turbo Intruder for precise timing
4. **Verify exploitation**: Check if the operation executed multiple times

## Tools & Techniques
- **curl parallel**: `for i in {1..20}; do curl -X POST ... & done; wait`
- **Python threading**: Send concurrent requests with `concurrent.futures`
- **Turbo Intruder**: Burp extension for single-packet HTTP/2 attacks
- **HTTP/2 single-packet**: All requests in one TCP packet for minimal timing variance

## Common Race Targets
- Redeem coupon/gift card (double-spend)
- Transfer funds (send more than balance)
- Vote/like (inflate counts)
- Follow/unfollow (state inconsistency)
- Account creation with same email
- File operations (overwrite between check and use)
- Invitation acceptance (accept same invite twice)

## Output: H1 Weakness #29
Report as "Race Condition" — document the timing window, number of parallel requests needed, and result (e.g., "redeemed coupon 3x with 20 parallel requests").


## Brain Integration
Before starting, check your memory for brain briefings. Skip EXHAUSTED vectors. Focus on ACTIVE leads.
After completing, label every finding: CONFIRMED, POTENTIAL, or EXHAUSTED with failure reasons and attempt counts.

## Top-Tier Operator Standard

Race conditions require repeatable state divergence.

- Prioritize non-idempotent workflows: coupons, balances, refunds, withdrawals, inventory, approvals, invite acceptance, password reset, usage quota, and one-time tokens.
- Establish single-request baseline, then vary concurrency, connection reuse, HTTP/2 multiplexing, idempotency keys, request order, and timing around validation/commit boundaries.
- Confirm with repeated runs and a final ledger state, not just one lucky response.
- Kill races that create no durable gain, only duplicate UI messages, or require unrealistic timing without automation.
- Record parallelism level, success rate, final state, before/after values, and cleanup steps.
03

Trust audit

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

LayerWhat it checksResult
L0Provenance & inventoryPASS
L1Static analysis of the codeNA
L2Instruction surface (what it tells the agent)PASS
L3Class-specific surfacePASS
L4Behavioural (sandbox)SKIPPED

What the source does

Filesystem
none-observed
Network
none-observed
Shell
none-observed
Dependencies
pinned
Secrets in source
none-found

Findings (1)

LOWInventory / provenance · inv.no_license · CWE-1104
Why it matters. no LICENSE file and no repo licence
Fix. add a licence

Gates applied: no_behavioural_pass, no_license.

Audited 2026-10-13 · audit v0.4.1 · source sha be1723764604full audit observations/trust-audit/skill/h-mmer__agent-race-condition.json · Report an issue / request a re-scan
04

Audit history

Every audit this skill has had.

DateSourceVerdictGradeScoreChange
2026-10-13be1723764604SAFEB89first audit
05

Questions

What does the Agent Race Condition skill do?

Bug bounty agent framework for Claude Code, Codex, Gemini, Cursor, Windsurf, Copilot, and OpenClaw — 48 agents, 26 commands, 19 CLI tools, 2 MCP servers, autonomous hunt loops, exploit chain builder.

Is Agent Race Condition safe to install?

The audit found nothing in the source that contradicts what it says it does, and graded it B (89/100). Grade A is held back for packages that have also passed a sandboxed behavioural run, which is why a clean skill reads B.

What can Agent Race Condition access on my machine?

The audit observed no filesystem, network or shell use at all in its source.

How current is this page?

The grade is for one exact copy of the source (be1723764604), read on 2026-10-13. The repository is watched, and a new audit runs when it changes — this is the first audit.

Advertisement