I recently discovered an interesting race condition vulnerability in the eCommerce software nopCommerce, during a manual pen test as part of the SWAT service (SWAT is Outpost24’s Pen Testing as a Service solution). This vulnerability (CVE-2024-58248) involves nopCommerce, an open-source eCommerce platform written in C#, which aids developers in building online stores. When exploited, it allows an attacker user to redeem a gift card multiple times by using a technique called a single-packet attack. If they did this correctly, they were able to receive items for free. 

I’ll walk through how I discovered this specific CVE, plus share what you need to know about race condition vulnerabilities and single-packet attacks.

How CVE-2024-58248 is exploited

An attacker is able to add items to the cart in two different sessions and then in each respective session enter the same gift card code. They can then continue through the checkout process in each session until they reach the page that contains the “Confirm” button. Here, if the attacker intercepts the outgoing request towards the /checkout/OpcConfirmOrder/, they can then perform a single-packet attack.

When both requests get processed in parallel, they each check the gift card balance before it gets updated with the new value, resulting in a race-condition where the balance is overdrawn. 

Timeline of events

• 07-08-2024: Discovery date of vulnerability
• 08-08-2024: Initial contact made with vendor
• 21-08-2024: Write up sent to vendor
• 29-08-2024: Vulnerability acknowledged by vendor
• January 2025: MITRE contacted
• April 2025: MITRE provide CVE number

It should be noted that the vendor communicated that they patched the vulnerability in December 2024. When the patch was released, we analyzed it as a part of the responsible disclosure process. We found that vulnerability persisted with a slight modification to the recreation flow and have notified the vendor about our findings in line with our Responsible Disclosure Policy. In addition, we have decided to share the details in this blog to raise awareness.

What are race condition vulnerabilities?

A race condition occurs when two or more threads, processes, or external actors access and manipulate the same shared resource (memory, file, hardware device, etc.) concurrently, and the final outcome depends on the exact interleaving of their operations. Because that interleaving is nondeterministic, you can get unexpected (or outright incorrect) behavior.

A race condition is fundamentally about timing and concurrency. Whenever multiple actors interact with the same mutable state without coordination, their actions can overlap in unpredictable ways, potentially leading to logic errors, inconsistency, crashes, or even security vulnerabilities. Proper synchronization (or better yet, designs that avoid shared mutable state altogether) are the keys to preventing them.

How race conditions work

An example of a race condition in the context of a web application could be if the application has a raffle in which a user only is able to participate once. The application keeps track if a user has participated with the variable has_participated, which defaults to false and gets set to true when a user enters the raffle. When a user enters the raffle, the application might do the following:

1. Checks the has_participated variable to see if the user has participated already
2. Enters the user in the raffle pool
3. Sets the has_participated variable to true

If there are no synchronization or locking mechanisms in place, this will create a race condition in the situation where two or more requests from the same user get processed in parallel. The requests “race” against each other to pass the check in step 1, before the variable get updated in step 3 – allowing a user to enter the raffle multiple times.

Why race conditions are hard to catch

• Non determinism: They often only occur under particular timing or load conditions, so tests may pass 999 times and then fail unpredictably on the 1000th.
• Heisenbugs: Simply adding logging or stepping through a debugger can alter the timing enough to hide the bug.
• Scale: In distributed systems, network latency and clock skew introduce additional nondeterminism.

What is a single-packet attack?

The single-packet attack is a technique initially brought forward by James Kettle at PortSwigger, which allows two or more requests to arrive at the server and be processed almost simultaneously. It does this by sending part of each request, while withholding the last bytes of each. Then in a single TCP packet (hence the name) the last bytes of each request are sent. This means that the server will not start to process the requests until the packet containing the final bytes is received. In turn, this allows the request to be processed in parallel.  

With this technique, network jitter and other external factors become minimal, allowing requests to arrive almost simultaneously. This opens the door to timing attacks and race conditions that were previously not considered feasible. 

Find vulnerabilities with SWAT

Test your apps in real-time for the latest vulnerabilities. SWAT delivers continuous monitoring of internet facing web applications via a SaaS delivery model. The solution can be fully customized to your needs, minimizing unnecessary load, or risk to any sensitive environments.

Most vulnerability findings are produced by our in-house testing team, and peer reviewed by a senior pen tester. You can also interact directly with our security experts for validation and remediation guidance, all via the portal. Book your live demo today.