Race Condition Exploit Lab

Race Conditions and TOCTOU Vulnerabilities

Web servers are built to handle many requests simultaneously. That concurrency is essential for performance — but it introduces a category of vulnerability that has nothing to do with malformed input or weak cryptography. It has everything to do with timing.

A race condition occurs when two operations execute concurrently against a shared resource and the outcome depends on which one finishes first. When the application assumes that no one else is acting on the same data between its read and its write, an attacker who can control the timing can violate that assumption.

TOCTOU: The Check-Then-Act Problem

The specific pattern you will exploit in this lab is called TOCTOU — Time-Of-Check to Time-Of-Use. Every TOCTOU vulnerability has the same shape:

1. The application checks a condition: "Is this coupon already used?"
2. The application uses the result: "Mark it used and credit the account."

Between step 1 and step 2 there is a window — a gap measured in milliseconds — during which the database has been read but not yet written. If a second request can complete its own check during that window, both requests will observe the same "not yet used" state. Both will proceed to the use phase. The coupon is credited twice.

The Starbucks Double-Spend (2015)

In 2015, researchers demonstrated that the Starbucks gift card transfer endpoint was vulnerable to a race condition. By sending a large number of parallel transfer requests simultaneously, users could transfer more than the card held. Each request passed the balance check before any debit committed to the database. The result was a balance multiplication that allowed users to generate effectively unlimited gift card credit.

The Robinhood Infinite Cash Glitch (2019)

Robinhood, the trading application, suffered a publicly reported race condition in 2019. Users discovered that placing certain option trades in rapid parallel succession could create a buying power figure that did not reflect actual account holdings. The underlying issue was a non-atomic balance check across multiple option legs being processed simultaneously. Users demonstrated the flaw live on social media before Robinhood patched it.

Why Web Applications Are Particularly Vulnerable

Several factors converge to make web applications a natural environment for race conditions:

• Stateless HTTP — each request is independent and the server cannot inherently serialize them.
• Connection pooling — database connections are shared across threads, and multiple threads can execute overlapping transactions against the same row.
• Async processing — frameworks that handle requests asynchronously can interleave operations that developers assumed would be sequential.

What You Will Do in This Lab

You will use an interactive panel to:

1. Observe a coupon redemption endpoint (SUMMER50) that is vulnerable to a TOCTOU race.
2. Use a parallel request slider to send 1 to 20 simultaneous redemption requests.
3. Identify the threshold at which multiple requests win the race and credit the account more than once.
4. Report the minimum parallel count that reliably exploits the race window.

By the end of this exercise you will have demonstrated the exploit and be ready to learn the atomic database patterns that close the TOCTOU window permanently.