0%
Some vulnerabilities announce themselves with crashes, warnings, or obvious red flags. Others slip quietly through the cracks—exploiting timing, sequence, and concurrency to break systems from the inside out. Race conditions belong to that second group.
They’re not flashy. They don’t always show up in scans. And they’re often dismissed as low-likelihood edge cases—until someone weaponizes them. At that point, the consequences aren’t just theoretical. Real-world breaches, privilege escalations, financial fraud, and authentication bypasses have all been traced back to well-timed race condition exploits.
What makes them especially dangerous is that they exploit logic, not just bugs. They creep in between a check and an action, or in the microseconds between two threads. And the more complex and asynchronous our systems become—microservices, multi-core processors, distributed cloud apps—the more opportunities they create for these vulnerabilities to emerge.
This blog unpacks how race conditions work in the wild, what makes them exploitable, and what modern teams can do to find, fix, and prevent them. Because ignoring them doesn’t make them rare. It just makes them harder to spot—until they break everything.
A race condition occurs when two or more processes attempt to access or modify the same resource—at the same time—and the outcome depends entirely on the sequence in which those operations complete. If they happen out of order, things go sideways fast: corrupted data, broken logic, privilege escalation, or even full system compromise.
Think of it like a relay race. If a runner grabs the baton too early or drops it during the handoff, the entire sequence breaks. In software, that baton could be a session token, a database row, or a critical file. Handle it out of sync, even by a few microseconds, and you’ve got more than a bug—you’ve got a security vulnerability.
Race conditions aren’t tied to any one language or platform. They show up in web apps, mobile clients, APIs, databases—anywhere concurrency exists. And they hide well. Under normal conditions, everything seems fine. But at scale, under stress, or during targeted attacks, the cracks begin to show.
That’s what makes race conditions especially dangerous: they don’t exploit flaws in code logic. They exploit the invisible timing gaps between operations—gaps most developers don’t even know exist.
For attackers, this makes race conditions ideal. They’re stealthy, low-profile, and often bypass traditional security checks. For defenders, detecting and mitigating them requires a deep understanding of how the system manages state, concurrency, and process synchronization.
These aren’t theoretical bugs. They’re practical threats that require deliberate design, testing, and architecture to prevent.
The race window is a narrow, dangerous slice of time when logic breaks down—usually between a check and an action or between two operations modifying the same resource. If an attacker acts within that precise window, they can bypass rules, corrupt data, or gain unauthorized access.
These windows may last milliseconds—or microseconds—but once discovered, they can be exploited with precision.
Here are real-world examples of where race windows appear:
Online Banking Transfers
There’s often a gap between checking an account balance and finalizing a transfer. If an attacker sends a second request during that window, they may overdraft or move more money than authorized.
File System Permissions
If one process checks file access while another changes permissions, the system might make decisions based on outdated info—allowing unauthorized access.
Authentication Flows
In login systems, attackers may flood the server to delay verification steps, slipping through before security checks finalize.
Database Updates
Without proper locking, simultaneous updates to the same record can overwrite each other, leading to corrupted or inconsistent data.
Ticketing Systems
A site that limits users to one ticket might still process multiple simultaneous requests if they hit before the “already purchased” check completes.
The core issue isn’t broken logic—it’s broken timing. And because these bugs hide between valid operations, they often go undetected in standard testing.
Understanding when and where these race windows occur is the first step toward eliminating them. Because until they’re closed, they remain silent threats hiding in plain sight.
Green Yellow Retro Parking Ticket
In a typical HTTP-based web application, these kinds of race conditions might be exploited by sending multiple HTTP requests in quick succession. For example:
POST /purchase\_ticket HTTP/1.1
Host: concerts.example.com
Host: concerts.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 58
user\_id=12345\&event\_id=67890\&quantity=1\&payment\_token=abcd1234
If an attacker sends multiple identical POST requests in quick succession, they can bypass ticket limits. This works because the server verifies the user’s purchase history before completing the transaction, leaving a brief race window where additional requests can slip through.
Single-endpoint race conditions occur when multiple concurrent requests hit the same endpoint and trigger unexpected behaviors due to shared state or timing gaps. These vulnerabilities are especially dangerous in web applications, where APIs and forms often rely on sequential logic that breaks under pressure.
The root issue? The server fails to handle simultaneous requests in a thread-safe way. If state changes aren’t atomic—or if session data can be overwritten mid-process—attackers can bypass controls, modify protected resources, or perform unauthorized actions.
Take a password reset function. A user requests a reset, receives a link with a token, clicks it, and resets their password. Simple—until someone sends two requests in rapid succession.
Here’s how the exploit works:
The attacker sends a password reset request for their own account. The server stores the username (attacker) and a reset token in the session.
Almost immediately, they send a second reset request—this time for the victim’s account. Same session. The server overwrites the username in session with victim and generates a new token.
The attacker then clicks the reset link (meant for their own account), but the session now references the victim’s username. The token matches. The server lets the attacker reset the victim’s password.
The race condition lies in how the session handles state between requests. Since the server doesn't isolate requests properly, timing alone lets an attacker cross account boundaries.
Race conditions like this don’t require advanced exploits or system-level bugs. They exploit logic and timing—two things developers often take for granted. And when a single endpoint handles sensitive state, it becomes the perfect target.
This vulnerability can be more clearly understood with the following HTTP requests:
First request to reset password for "attacker"
POST /reset\_password HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 27
[email protected]
Second request to reset password for "victim"
POST /reset\_password HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 26
[email protected]
By sending these two requests nearly simultaneously from the same browser session, the server's logic is tricked. It stores the token from the first request, but pairs it with the victim username from the second. When the attacker later uses the reset link, the session matches—and the victim’s password is reset by someone else.
Multi-endpoint race conditions happen when different parts of a system—APIs, web pages, or internal functions—interact with the same resource at the same time. These aren’t just concurrency issues in one place. They’re timing collisions across multiple endpoints that, on their own, seem secure—but together open dangerous gaps.
The complexity makes them harder to spot. The risk comes from how these separate pieces fit together. If timing isn't tightly controlled, one request can slip in during another's critical processing window—leading to logic breaks, bypassed checks, or corrupted state.
Let’s look at an online store with a typical purchase flow: add items to cart → verify balance → finalize order. Straightforward in theory. But now introduce some concurrency across endpoints.
Here’s how an attacker might exploit it:
Add to Cart:
The attacker adds an item to their cart. The system updates the cart state.
Start Checkout:
They initiate checkout. The system verifies that they have sufficient funds based on the current cart total.
Exploit the Race Condition:
Before checkout completes, the attacker sends a second request—this time to a different endpoint that adds another item to the cart. If this happens before payment is finalized, the new item slips through without a new funds check.
The result? The attacker receives more products than they paid for.
In a typical HTTP-based scenario, the requests might look like this:
First request \- Add item to cart
POST /add\_to\_cart HTTP/1.1
Host: shop.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 45
product\_id=12345\&quantity=1
Second request \- Checkout
POST /checkout HTTP/1.1
Host: shop.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 28
cart\_id=67890\&payment\_token=xyz789
Third request \- Add another item
POST /add\_to\_cart HTTP/1.1
Host: shop.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 45
product\_id=54321\&quantity=1
The timing is key. If the third request lands before the second finishes processing, the attacker gets an extra item without paying the correct amount. The endpoints worked fine in isolation—but concurrency broke the logic when they collided.
Send most of a request’s data first. Then hold back the final byte. When ready, release that last byte across multiple requests at the same time. This helps align their processing.
Example: A file upload handler receives two nearly complete requests that pause just before the final byte. When both final bytes are sent simultaneously, the server processes both uploads at the same time—potentially exposing a race condition.
Request 1 \- Partial transmission
POST /upload\_file HTTP/1.1
Host: example.com
Content-Type: multipart/form-data; boundary=---12345
Content-Length: 5000
\---12345
Content-Disposition: form-data; name="file"; filename="file1.txt"
Content-Type: text/plain
... (4999 bytes of file data)
Request 2 \- Partial transmission
POST /upload\_file HTTP/1.1
Host: example.com
Content-Type: multipart/form-data; boundary=---12346
Content-Length: 5000
\---12346
Content-Disposition: form-data; name="file"; filename="file2.txt"
Content-Type: text/plain
... (4999 bytes of file data)
Final byte sent simultaneously for both requests
... (final byte of both requests sent together)
By synchronizing the transmission of the final byte, you increase the chances of both requests being processed at the same time, potentially exploiting a race condition in the file upload handling.
HTTP/2 lets you send multiple requests over one TCP connection—in a single packet. That makes them land together on the server with near-perfect timing.
Great for login races or token checks, these attacks reduce timing variability, letting attackers sneak multiple simultaneous requests through tight windows.
Example: An attacker submits two login requests—one with a regular account, one with elevated privileges—inside a single HTTP/2 packet. If the server fails to handle simultaneous login attempts securely, it may incorrectly elevate the attacker's session by overlapping request states.
Multiple requests sent over a single TCP connection
POST /login HTTP/2
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 50
username=attacker\&password=password123
POST /login HTTP/2
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 50
username=admin\&password=password456
In this example, both login requests are sent as part of a single packet, ensuring that the server processes them in rapid succession. If a race condition exists, this could allow the attacker to gain unauthorized access.
Even perfect packet timing can stumble on cold-start latency. Connection warming helps.
By sending harmless dummy requests first, attackers ensure the server is ready—sockets open, threads allocated, caches warmed—so that real attack requests hit fast and simultaneously.
Example: Before hitting an account deletion endpoint, attackers warm up the connection with lightweight dummy requests to reduce latency and align the real attack requests for maximum effect.
Dummy requests to warm up the connection
POST /api/dummy HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
action=warmup1
POST /api/dummy HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
action=warmup2
Actual attack requests sent after warming up the connection
POST /api/delete\_account HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 50
user\_id=12345\&confirm=true
POST /api/delete\_account HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 50
user\_id=67890\&confirm=true
By warming up the connection with dummy requests, you reduce the variability in processing times, increasing the chances of your attack succeeding.
Warming up isn’t always enough. When rate limits or load guards are in place, attackers may need to bend the rules further.
By hammering the server with dummy requests, attackers can introduce load-based delays. These delays open up precise timing windows for their actual exploit attempts.
Example: In a financial app, attackers flood an API with zero-amount requests to degrade performance. Then, they send high-value transactions close together, exploiting the lag to bypass validation.
Dummy requests to trigger server-side delay
POST /api/transaction HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
amount=0\&dummy=true
POST /api/transaction HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
amount=0\&dummy=true
\# Actual attack requests sent after triggering delay
POST /api/transaction HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 50
amount=1000\&account=12345
POST /api/transaction HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 50
amount=1000\&account=67890
By flooding the server with dummy requests, you create a delay that allows your actual transaction requests to be processed simultaneously, increasing the likelihood of exploiting the race condition.
Exploiting race conditions isn’t just about speed—it’s about timing. But hitting the right moment is tricky. Network jitter, internal latency, and concurrency all introduce uncertainty. That’s why attackers use synchronization techniques tailored to how servers handle HTTP traffic.
This is the unpredictable delay in request delivery across a network. Even a few milliseconds of variation can ruin the synchronization needed to trigger a race condition.
Servers introduce their own delays. Thread scheduling, resource contention, and queuing can all affect how fast (or slow) a request is processed—making timing even harder.
Because HTTP/1.1 and HTTP/2 handle connections differently, attackers adapt their techniques to each. The goal? Precision. Getting multiple requests to hit the server at just the right time.
Preventing race conditions starts with deliberate design and disciplined coding. It’s not just about writing code—it’s about writing it defensively, with concurrency in mind. Here are key strategies:
Use Atomic Operations: Ensure critical code sections execute without interruption to prevent interference from other threads.
Apply Proper Locking: Use locks or mutexes to control access to shared resources and avoid conflicting operations.
Leverage Thread-Safe Structures: Use built-in thread-safe data structures to simplify safe concurrent access.
Defensive Programming: Validate inputs, check assumptions, and guard against unexpected states.
Thorough Testing: Run stress, concurrency, and fuzz tests to uncover race conditions before attackers do.
Static Analysis Tools: Use tools that detect race-prone patterns early in development.
Minimize Shared State: Reduce shared data across threads to simplify synchronization.
Race conditions won’t fix themselves. They require constant attention—from architecture to testing. The fewer assumptions your system makes about timing, the more resilient it becomes.
Race conditions are a serious cybersecurity challenge that demand a deep understanding of concurrent programming, system design, and vulnerability patterns. From simple single-endpoint issues to complex multi-endpoint scenarios, these flaws can be subtle yet highly exploitable.
Addressing race conditions requires a layered approach:
As systems become more distributed and concurrency-heavy, the risk of race conditions will only grow. Staying updated on both exploitation techniques and prevention best practices is essential.
Ultimately, security isn’t just a feature—it’s a habit. Developers and security teams must prioritize race condition awareness throughout the development lifecycle. With the right mindset and safeguards, it’s possible to build software that’s not only functional, but also resilient under pressure.
By taking these steps, organizations can better defend against timing-related vulnerabilities and strengthen the overall integrity of their applications.
Need help identifying or testing for race conditions in your systems?
Talk to our team—we help organizations detect, validate, and remediate timing-based vulnerabilities across complex systems.
Head of Security testing