What Is a Race Condition Vulnerability and How Is It Exploited?

A race condition vulnerability occurs when a system’s security depends on operations completing in a specific order, and an attacker can interfere with that order by timing simultaneous requests. The most dangerous variants allow double-spending in payment systems, privilege escalation in file operations, and authentication bypass in session handling.

Analysis Briefing

• Topic: Race condition vulnerabilities in web and file system security
• Analyst: Mike D (@MrComputerScience)
• Context: Sparked by a question from Gemini 2.0 Flash
• Source: Pithy Security
• Key Question: How does sending two requests at exactly the same moment bypass security controls?

---

Why TOCTOU Flaws Let Attackers Swap Files Mid-Check

Time-of-Check to Time-of-Use (TOCTOU) is the file system variant of race conditions. An application checks whether a file is safe, then uses it. An attacker replaces the file between the check and the use. The check passes on the safe file. The operation executes on the malicious one.

Privileged programs that check file ownership or permissions before processing them are classic TOCTOU targets. An attacker who can replace a file with a symlink to /etc/shadow after the permission check but before the read operation gains access to files the application was never intended to read.

Operating system-level mitigations like O_NOFOLLOW and openat() with directory file descriptors reduce the TOCTOU window significantly. Applications that check and open in a single atomic operation using these primitives are not vulnerable to symlink attacks.

How Double-Spend Race Conditions Bypass Payment Controls

Web application race conditions typically target operations that check a condition, then act on it, in non-atomic steps. A gift card redemption endpoint that checks the balance and deducts it in two separate database operations is vulnerable if an attacker sends parallel requests during the window between check and deduction.

Both requests read the balance before either write commits. Both see sufficient balance. Both deduct the full amount. The account ends up with double the expected spend.

Portswigger’s research on “limit overrun” race conditions in 2023 demonstrated this class of vulnerability in widely deployed e-commerce platforms. The exploitation technique, single-packet attacks that synchronize parallel HTTP/2 requests to arrive simultaneously, is now well-documented and actively tested in bug bounty programs.

When Database Transactions Actually Prevent Race Conditions

Proper database transactions with appropriate isolation levels eliminate race conditions in most web application contexts. A transaction that reads and writes a balance atomically, with a SELECT FOR UPDATE lock, prevents concurrent reads from seeing the pre-update value.

The failure mode is partial transaction use. An application that wraps the write in a transaction but performs the read outside it is still vulnerable. Both the read and the conditional write must be inside the same transaction with a row-level lock for the protection to hold.

Redis atomic operations (SETNX, Lua scripts) provide the same guarantee for cache-based counters. Distributed locks using Redis Redlock or database advisory locks handle cross-service coordination where a single transaction is not possible.

What This Means For You

• Audit every balance-check-then-deduct operation in your payment and entitlement code, because non-atomic check-then-act patterns are the most commonly exploited race condition in web applications.
• Use SELECT FOR UPDATE on any database read that conditions a subsequent write in the same transaction, because row-level locking is the standard fix for database-layer race conditions.
• Test your endpoints with parallel requests using HTTP/2 single-packet attacks, because Burp Suite’s Turbo Intruder and the single-packet technique expose race conditions that sequential testing misses entirely.
• Replace file-path operations with file-descriptor operations in privileged code, because open() then fstat() on the descriptor is TOCTOU-safe where stat() then open() on the path is not.

---

Enjoyed this deep dive? Join my inner circle:

• Pithy Security → Stay ahead of cybersecurity threats.