This is the story of how a "boring" e-commerce site turned into a playground for a Race Condition vulnerability. If you think hacking is all about sophisticated code injection, you're missing the easiest way to make a platform cry: doing everything at once.
Most people don't realize that computers are actually quite bad at multitasking when they're in a hurry. When a server gets hit with ten requests at the exact same millisecond, it starts to trip over its own feet.
That's exactly how I "bought" a top-tier MacBook Pro for negative $300.
The Setup: The "Add to Cart" Obsession
I was testing a major international retail platform. Their checkout process was standard, but they had a very aggressive marketing campaign running: "Use code SAVE50 for $50 off your first order."
Most hunters would try to use the code twice on one account. I tried that; the UI gave me a polite "Coupon already used" message. They were checking the database to see if my user_id had already claimed the discount.
But I wondered: How fast is that check?
The Theory: The "Race" for the Database
In programming, there's a window of time between a server reading a value (is the coupon used?) and writing a value (mark coupon as used).
If I could send a second, third, and fourth request before the first request finished writing the "used" status to the database, the server might think the coupon was still valid for every single one of those requests.
This is a Race Condition. I wasn't breaking the encryption; I was just beating the server to the finish line.
The Attack: 20 Requests, 1 Millisecond
I added a $2,000 MacBook to my cart. I fired up Burp Suite and used the Turbo Intruder extension — a tool designed to send HTTP requests at a speed that would make a human head spin.
I set up a script to send 20 "Apply Coupon" requests simultaneously.
- Request 1: Is coupon used? No. Apply -$50.
- Request 2: (Sent 0.001ms later) Is coupon used? The first request hasn't finished yet, so the answer is still "No." Apply -$50.
- Request 3: Is coupon used? Still "No." Apply -$50.
I hit "Start Attack."
The Result: The "Impossible" Invoice
I went back to my browser and refreshed my cart. I expected it to either show $1,950 or just error out.
Instead, the "Total Price" line read: $1,700.00.
The server had processed the coupon six times. I had successfully "raced" the database and won. But I didn't stop there. I wondered if the system had a "floor" for how low the price could go.
I re-ran the script, but this time I sent 50 requests.
The page refreshed. The total price was now -$300.00. Because the system didn't have a logic check to ensure the total couldn't be less than zero, the store technically owed me money to ship me a flagship laptop.
The Triage and The Payday
I recorded my screen, showing the cart total dropping with every execution of the script. I didn't actually hit the "Place Order" button — doing so would move from "bug hunting" to "fraud," and that's a quick way to get a visit from the police instead of a bounty.
I submitted the report to their security team under the Business Logic / Race Condition category.
The Timeline:
- Submitted: 3:00 PM
- Status "Triaged": 5:15 PM (The developers were shocked they hadn't implemented "row locking" on the coupon table).
- Bounty Awarded: $2,500.
Why This is a "Viral" Bug
Race conditions are the "silent killers" of web apps. They are notoriously hard for developers to test for because they only happen under high-concurrency loads.
The Lessons for You:
- Identify the "Write" Action: Look for anywhere the server updates a balance, a count, or a status (like a "Like" button, a "Vote," or a "Coupon").
- Use the Right Tools: You can't do this manually. Tools like Turbo Intruder or Go scripts are your best friends.
- Check the "Negative" Logic: Always see if you can push a value below zero. If you can, you've usually found a goldmine.
Sometimes, the best way to hack a system isn't to be smarter than the code it's just to be faster.