Advent of Cyber 2025 Day 20 Walkthrough Race Conditions – Toy to The World
Task 1 Introduction
Click here to access the Advent of Cyber 2025 Day 20 Walkthrough Race Conditions – Toy to The World Room Lab
The Story Advent of Cyber 2025 Day 20 Walkthrough Race Conditions – Toy to The World

The Best Festival Company (TBFC) has launched its limited-edition SleighToy, with only ten pieces available at midnight. Within seconds, thousands rushed to buy one, but something strange happened. More than ten lucky customers received confirmation emails stating that their orders were successful. Confusion spread fast. How could everyone have bought the “last” toy? McSkidy was called in to investigate.
She quickly noticed that multiple buyers purchased at the exact moment, slipping through the system’s timing flaw. Sir Carrotbane’s mischievous Bandit Bunnies had found a way to exploit this chaos, flooding the checkout with rapid clicks. By morning, TBFC faced angry shoppers, missing stock, and a mystery that revealed just how dangerous a few milliseconds could be during the holiday rush.
Learning Objectives
- Understand what race conditions are and how they can affect web applications.
- Learn how to identify and exploit race conditions in web requests.
- How concurrent requests can manipulate stock or transaction values.
- Explore simple mitigation techniques to prevent race condition vulnerabilities.
Connecting to the Machine
Before moving forward, review the questions on the connection card below:

Start your target VM by clicking the Start Machine button below. The machine will need about 2 minutes to fully boot. Additionally, start your AttackBox by clicking the Start AttackBox button below. The AttackBox will start in split view. In case you can not see it, click the Show Split View button at the top of the page. Once the machine is up and running, you can access the application by visiting http://MACHINE_IP in the browser of your AttackBox.
Set up your virtual environment
To successfully complete this room, you’ll need to set up your virtual environment. This involves starting both your AttackBox (if you’re not using your VPN) and Target Machines, ensuring you’re equipped with the necessary tools and access to tackle the challenges ahead.

Answer the questions below
I can successfully connect to the machine.
No answer needed
Task 2 Race Condition
A race condition happens when two or more actions occur at the same time, and the system’s outcome
 depends on the order in which they finish. In web applications, this often happens when multiple users or automated requests simultaneously access or modify shared resources, such as inventory or account balances. If proper synchronisation isn’t in place, this can lead to unexpected results, such as duplicate transactions, oversold items, or unauthorised data changes.
Types of Race Conditions
Generally, race condition attacks can be divided into three categories:
- Time-of-Check to Time-of-Use (TOCTOU): A TOCTOU race condition happens when a program checks something first and uses it later, but the data changes in between. This means what was true at the time of the check might no longer be true when the action happens. It’s like checking if a toy is in stock, and by the time you click “Buy” someone else has already bought it. For example, two users buy the same “last item” at the same time because the stock was checked before it was updated.
- Shared resource: This occurs when multiple users or systems try to change the same data simultaneously without proper control. Since both updates happen together, the final result depends on which one finishes last, creating confusion. Think of two cashiers updating the same inventory spreadsheet at once, and one overwrites the other’s work.
- Atomicity violation: An atomic operation should happen all at once, either fully done or not at all. When parts of a process run separately, another request can sneak in between and cause inconsistent results. It’s like paying for an item, but before the system confirms it, someone else changes the price. For example, a payment is recorded, but the order confirmation fails because another request interrupts the process.
Time for Some Action
Now that we understand the basic concepts, let’s take the example of the TBFC shopping cart app and exploit the race condition.
Configuring the Environment
First, we will configure Firefox to route traffic through Burp Suite. On the AttackBox, open Firefox, click the FoxyProxy icon (1) and select the Burp profile (2) so all browser requests are sent to Burp, as shown below:

Next, click on the Burp Suite icon on the Desktop to launch the application.

You will see an introductory screen; choose Temporary project in memory and click Next.

On the configuration screen, click Start Burp to start the application.

Once the application is started, you will see the following screen, where we will use the Proxy and Repeater option to exploit the race condition.

Before proceeding, ensure that you turn off “Intercept” in Burp Suite. Open the Proxy tab and check the Intercept sub-tab; If the button says “Intercept on“, click it so it changes to “Intercept off“. This step ensures that Burp Suite no longer holds your browser requests and allows them to pass through normally.

Making a Legitimate Request
Now that the environment is configured, make a normal request. Open Firefox, visit the webapp at http://MACHINE_IP, and you will see the following login page:

On the site’s login panel, enter the credentials, username: attacker and password: attacker@123. After logging in, you’ll arrive at the main dashboard, which shows the limited-edition SleighToy with only 10 units available.

To make a legitimate purchase, click Add to Cart for the SleighToy and then click Checkout to go to the checkout page.

On the checkout page, click Confirm & Pay to complete the purchase. You should see a success message confirming the order, as shown below:

Exploiting the Race Condition
Now that we have made a legitimate request, navigate back to Burp Suite and click on Proxy > HTTP history and find the POST request to the /process_checkout endpoint created by our legitimate checkout request. Right-click that entry and choose Send to Repeater, which will copy the exact HTTP request (headers, cookies, body) into Burp’s Repeater tool as shown below:

Next, switch to the Repeater tab and confirm the request appears there, right-click on the first tab, select Add tab to group, and click on Create tab group.

Enter a name for the tab group, such as cart, and click Create, which will create a tab group named cart.

Then, right-click the request tab and select Duplicate tab. When prompted, enter the number of copies you want (for example, 15). You’ll now have that many identical request tabs inside the cart group.

Next, use the Repeater toolbar Send dropdown menu and select Send group in parallel (last-byte sync), which launches all copies at once and waits for the final byte from each response, maximising the timing overlap to trigger race conditions.

Once this is done, click Send group (parallel); this will launch all 15 requests to the server simultaneously. The server will attempt to handle them simultaneously, which will cause the timing bug to appear (due to multiple orders being processed at once).

Finally, visit the web app, and you will see multiple confirmed orders and the SleighToy stock reduced (possibly going negative).

Mitigation
The attacker logged in and made a normal purchase of the limited SleighToy. Using Burp Suite, he captured the checkout request and sent it multiple times in parallel. Because the app didn’t handle simultaneous checkouts correctly, each request succeeded before the stock could update. This allowed the attacker to buy more toys than available, resulting in a race condition and pushing the stock into negative values. Here are a few mitigation measures to avoid the vulnerability:
- Use atomic database transactionsso stock deduction and order creation execute as a single, consistent operation.
- Perform a final stock validation right before committing the transaction to prevent overselling.
- Implement idempotency keys for checkout requests to ensure duplicates aren’t processed multiple times.
- Apply rate limiting or concurrency controls to block rapid, repeated checkout attempts from the same user or session.
Answer the questions below
What is the flag value once the stocks are negative for SleighToy Limited Edition?
THM{WINNER_OF_R@CE007}
Repeat the same steps as were done for ordering the SleighToy Limited Edition. What is the flag value once the stocks are negative for Bunny Plush (Blue)?
THM{WINNER_OF_BUNNY_R@CE}
Feel free to check out the Race Conditions room if you enjoyed this task.
No answer needed
Completion Message – Advent of Cyber 2025 Day 20
Congratulations! 🎉 You’ve successfully completed Advent of Cyber 2025 Day 20 Walkthrough – Race Conditions: Toy to The World.
In this lab, you learned how race condition vulnerabilities occur in real-world web applications and how attackers can exploit timing flaws using concurrent requests. By leveraging Burp Suite Repeater and sending parallel checkout requests, you were able to manipulate inventory logic, force negative stock values, and retrieve both challenge flags.
This task highlighted the critical importance of atomic transactions, concurrency control, and proper validation in high-traffic applications especially during peak events like limited-edition product launches. Excellent work sharpening your web exploitation and defensive security knowledge! 🚀
Related Resources
- Advent of Cyber 2025 Prep Track
- Advent of Cyber 2025 Day 1 Walkthrough Linux CLI Shells Bells
- Advent of Cyber 2025 Day 2 Phishing Merry Clickmas
- Advent of Cyber 2025 Day 3 Walkthrough Splunk Basics – Did you SIEM?
- Advent of Cyber 2025 Day 4 Walkthrough AI in Security old sAInt nick
- Advent of Cyber 2025 Day 5 Walkthrough IDOR Santa’s Little IDOR
- Advent of Cyber 2025 Day 6 Walkthrough Malware Analysis Egg xecutable
- Advent of Cyber 2025 Day 7 Walkthrough Network Discovery Scanta Clause
- Advent of Cyber 2025 Day 8 Walkthrough Prompt Injection Schedyule conflict
- Advent of Cyber 2025 Day 9 Walkthrough Passwords A Cracking Christmas
- Advent of Cyber 2025 Day 10 Walkthrough SOC Alert Triaging – Tinsel Triage
- Advent of Cyber 2025 Day 11 Walkthrough XSS Merry XSSMas
- Advent of Cyber 2025 Day 12 Walkthrough Phishing Phishmas Greetings
- Advent of Cyber 2025 Day 13 Walkthrough YARA Rules YARA mean one
- Advent of Cyber 2025 Day 14 Walkthrough Containers DoorDasher’s Demise
- Advent of Cyber 2025 Day 15 Walkthrough Web Attack Forensics – Drone Alone
- Advent of Cyber 2025 Day 16 Walkthrough Forensics – Registry Furensics
- Advent of Cyber 2025 Day 17 Walkthrough CyberChef – Hoperation Save McSkidy
- Advent of Cyber 2025 Day 18 Walkthrough Obfuscation – The Egg Shell File
- Advent of Cyber 2025 Day 19 Walkthrough ICS/Modbus – Claus for Concern
- TryHackMe CTF Writeups & Walkthrough Roadmap
FAQs – Advent of Cyber 2025 Day 20 Walkthrough
1. What is a race condition?
A race condition occurs when two or more processes access and modify shared resources simultaneously, and the final outcome depends on the order in which the operations complete. In web applications, this can lead to issues like overselling products, duplicate transactions, or inconsistent data.
2. What are the main types of race conditions?
1. Time-of-Check to Time-of-Use (TOCTOU): When a system checks a condition and then performs an action, but the data changes between these steps.
2. Shared resource race: When multiple users or processes update the same resource simultaneously without proper synchronization.
3. Atomicity violation: When an operation meant to be executed as a single unit is interrupted, allowing another request to interfere.
3. How was the race condition exploited in Day 20?
A legitimate purchase request for the limited-edition SleighToy was captured using Burp Suite.
The request was duplicated multiple times and sent in parallel using Burp Suite Repeater.
The server attempted to process all requests simultaneously, bypassing stock checks, causing negative inventory, and generating the flags.
4. What are the flags for Day 20?
SleighToy Limited Edition: THM{WINNER_OF_R@CE007}
Bunny Plush (Blue): THM{WINNER_OF_BUNNY_R@CE}
5. How can race conditions be prevented?
Use atomic database transactions for critical operations like stock deduction and order creation.
Validate inventory immediately before committing the transaction.
Implement idempotency keys for critical requests to prevent duplicate processing.
Apply rate limiting and concurrency controls to block rapid repeated requests.
6. Why are race conditions important to understand in cybersecurity?
Race conditions can be exploited to bypass application logic, steal goods, or manipulate financial transactions. Understanding them helps developers secure applications and helps ethical hackers identify vulnerabilities in penetration testing.
7. Which tools were used in this walkthrough?
Burp Suite: Proxy, HTTP history, Repeater (to capture and replay requests)
Firefox: Configured with FoxyProxy to route traffic through Burp Suite
AttackBox & Target VM: Virtual environment for practicing the exploit
3 Comments