🔓 Free Link

Table of Contents

1. Summary of the Vulnerability
2. Proof of Concept (PoC)
3. Impact

Summary of the Vulnerability

A multi-endpoint race condition occurs when multiple related requests are processed by different backend endpoints without proper synchronization. In this lab, the vulnerability exists in the purchasing workflow, where the order creation and checkout confirmation are handled by separate requests that are not executed atomically. Because these endpoints do not share a consistent transaction state, it becomes possible to manipulate the timing between them.

During testing, the purchase flow was analyzed by ordering a gift card to understand how the application processes cart updates and checkout validation. The observation revealed a small timing gap between the moment the order is registered and the moment the checkout process validates the total cost. The checkout request can complete before the order state is fully updated, creating a window where multiple requests can be processed with outdated balance information.

By adding a Lightweight L33t Leather Jacket and a gift card to the cart, then sending the order-related requests in parallel, the backend processes both operations using the same account balance.

Because the balance check is not locked to a single transaction, both items are approved even though the account only contains $100. This allows the attacker to bypass the intended business logic and purchase items for an unintended price.

Proof of Concept (PoC)

Steps to Reproduce

• Log in using the account wiener:peter. After logging in, the account balance is $100, which will be used during the purchasing process.

• To understand how the order and checkout workflow works, first purchase a simple product as a test. In this case, use the Gift Card product because the code can be redeemed later to restore the balance back to $100.

• Observe the HTTP traffic during the purchase flow. You will notice that the application sends two separate requests during the process:

- Request for adding the product to the cart
- Request for checkout confirmation

• Send both requests to Burp Repeater for manual testing.

• Rename the tabs in Repeater to make the workflow easier to manage:

- Tab 1 → add-cart
- Tab 2 → cart-checkout

• Then group the requests:

- Right-click on cart-checkout
- Select Add tab to group → New tab group

• Make sure the group sending mode is set to:

Send group (single connection)

• When the requests are sent in this mode, you will notice a small delay of a few milliseconds between:

- the checkout process
- the cart update process

• Below is the checkout request

• Below is the add-to-cart request (gift card)

• This timing gap is the key condition that allows a race condition to occur.
• The goal is to purchase the product Lightweight L33t Leather Jacket with the productID = 1.

• Go back to Repeater and modify the request:

productID=1

• Then send the request again.

• At this stage, the server rejects the request because the balance is not sufficient. This is expected, since the requests are still being sent using single connection mode, meaning they are processed sequentially.
• Change the sending method to:

Send group (parallel)

• This forces both requests to be processed at the same time, which increases the chance of triggering the race condition.
• Reference:

https://portswigger.net/burp/documentation/desktop/tools/repeater/send-group#sending-requests-in-parallel

• Before sending the parallel requests, make sure the cart contains only 1 Gift Card.
• The Leather Jacket must not be in the cart. It will be injected through the modified request in Burp Repeater.
• Why keep the gift card in every attempt?

From testing, the checkout logic only succeeds when the system believes the purchase contains a valid low-cost item. By keeping the gift card in the cart, the backend processes the checkout as if only the gift card is being purchased, while the race condition allows the Leather Jacket to be included at the same time.

• First attempt — failed (only gift card purchased)

• Second attempt — still failed

Note: Before every attempt, the cart always contains only 1 gift card. No other products are added manually.

• Third attempt — success. Both items were processed in the same checkout transaction:

1 × Lightweight L33t Leather Jacket
1 × Gift Card

• Open the response in the browser and the lab shows that the purchase was successful.

Impact

A multi-endpoint race conditions in payment or checkout workflows can lead to financial loss and business logic bypass. If this vulnerability exists in an e-commerce platform, an attacker could:

• Purchase expensive items using insufficient balance
• Redeem discount codes multiple times before validation completes
• Generate store credits or gift cards without proper deduction
• Bypass payment verification by triggering checkout before the order state updates

📢 Enjoyed this post? Stay connected! If you found this article helpful or insightful, consider following me for more:

• 📖 Medium: bashoverflow.medium.com
• 🐦 Twitter / X: @_havij
• </> Github: havij13
• ☕ Coffee: Buymeacoffee

🙏Your support is appreciated.