What Is a Race Condition in Cyber Security? Exploiting Timing Vulnerabilities

A race condition in cyber security is a vulnerability where a system’s behavior depends on the uncontrolled timing between two or more concurrent operations, letting an attacker exploit the gap between when something gets checked and when it actually gets used.

This makes race conditions fundamentally different from most vulnerabilities security teams chase. A SQL injection flaw exists whether anyone tests it or not. A race condition often only becomes exploitable under specific timing conditions, sometimes triggering once in thousands of attempts, which is exactly why it slips past so many standard security reviews entirely.

TOCTOU: the gap between checking and acting

TOCTOU, Time-of-Check to Time-of-Use, describes the specific moment a program verifies something is safe, then relies on that verification a fraction of a second later, giving an attacker a narrow window to swap or alter the resource before the program actually acts on it.

Picture a program checking whether a file is safe to write to, then opening that file a moment later. If an attacker replaces the file with a symbolic link pointing somewhere sensitive during that exact gap, the program opens the wrong target entirely, still believing its earlier check was valid. This pattern shows up constantly in privileged software touching shared file systems, which is precisely why it remains one of the most consistently exploited race condition patterns across decades of vulnerability research.

CWE-362 and CWE-367: the formal classification, explained

CWE-362 is the general Race Condition weakness category in the Common Weakness Enumeration database, while CWE-367 is its more specific child classification covering TOCTOU race conditions directly, the exact check-then-act pattern described above.

Formal classification matters practically because it shapes how vulnerabilities get tracked and remediated across an organization. A vulnerability tagged CWE-362 broadly signals a timing-dependent flaw somewhere in concurrent code, while CWE-367 specifically points a developer toward the check-then-act pattern to review, narrowing the search considerably compared to auditing an entire codebase for generic concurrency issues.

A worked example: how a coupon or balance gets redeemed twice

Race condition exploits targeting business logic often follow a pattern called limit-overrun: an attacker sends multiple requests that each individually pass validation, but collectively exceed a limit the system was supposed to enforce, applying a single-use discount code twice or overdrawing an account balance.

A real, documented technique makes this exploit reliable in practice. Security researchers demonstrate exploiting coupon redemption logic by triggering checkout and adding an item to a cart simultaneously, since both requests arrive at the server at nearly the same instant, the server has to decide processing order under pressure, and a poorly synchronized system applies the discount to both requests before either one updates the “already used” status. The same limit-overrun pattern applies directly to gift card balances, loyalty points, and any system tracking a finite, shared resource across concurrent requests, since the underlying flaw is identical regardless of what’s being double-spent.

The single-packet attack: how researchers made timing windows exploitable at scale

The single-packet attack, published by James Kettle of PortSwigger Research in 2023, exploits HTTP/2’s ability to send multiple requests over one connection, withholding the final byte of each request until all are ready, then releasing them simultaneously to eliminate network jitter entirely.

This technique transformed race conditions from a theoretical, unreliable class of bug into something practically exploitable at scale. Before this research, remote race condition attacks suffered from network jitter, the natural, unpredictable delay between sending requests and their arrival, making reliable exploitation difficult even when a genuine vulnerability existed. Kettle’s technique squeezes roughly 30 requests sent across a real network into a sub-1-millisecond execution window, proving 4 to 10 times more effective than prior methods, and was used to discover a real, confirmed vulnerability, CVE-2022-4037, in GitLab. This research fundamentally changed how seriously security teams should treat race conditions, since what once required lucky timing now has a documented, repeatable, publicly available technique behind it.

Real CVEs: Dirty COW, Dirty Pipe and recent 2026 disclosures

Dirty COW, CVE-2016-5195, exploited a race condition in the Linux kernel’s copy-on-write memory mechanism, remaining unpatched for roughly nine years before a proper fix arrived in 2016, letting a local attacker turn a read-only file mapping into a writable one with the right timing. Dirty Pipe, CVE-2022-0847, followed a similar Linux kernel exploitation class in 2022.

Dirty COW’s attack leaves no trace in standard system logs, a detail that partly explains why it went undetected for nearly a decade despite affecting virtually every Linux and Android device running an older kernel. Its relevance hasn’t faded either: recent 2026 AI safety research testing frontier language models against container sandbox escape challenges found one model discovered an entirely unintended exploitation path using Dirty COW to bypass a different intended vulnerability, proving this decade-old race condition remains a genuinely viable privilege escalation technique even against modern, hardened environments.

Why automated scanners miss race conditions but manual testers find them

Automated vulnerability scanners cannot reliably detect race conditions because there’s no signature to match and no malformed payload to inject, the vulnerable code often looks completely correct in isolation, only failing under specific concurrent timing that a scanner sending sequential requests never triggers.

This is a genuine, structural blind spot in most security programs, not a tooling gap that better automation will eventually close. Manual testers find race conditions specifically by looking for check-then-act patterns in business logic, coupon redemption, password reset flows, account balance updates, then deliberately firing concurrent requests using tools built for this exact purpose. If your security program relies entirely on automated scanning results as evidence of coverage, race conditions represent a category of risk that evidence simply never surfaces, regardless of how frequently or expensively that scanning runs.

What is reverse engineering, and how does it uncover a hidden race window?

Analyzing compiled software without source code access to understand its internal logic, a skill that becomes essential for finding race conditions in closed-source applications where the check-then-act pattern isn’t visible in any code review.

Reverse engineering a binary’s authentication or transaction-handling routines often reveals exactly where a check happens and how much time separates it from the corresponding action, information an attacker or a defensive researcher needs before attempting to exploit or patch the timing gap. This is particularly relevant for proprietary financial software, embedded firmware, and legacy applications where source code either doesn’t exist anymore or was never available, making reverse engineering the only practical path to finding a race condition hiding inside logic nobody can directly read.

Fixing it: atomic operations, locking and idempotency keys

Fixing race conditions means making the check-and-act sequence atomic, a single, uninterruptible operation, using database-level locking, or attaching idempotency keys to requests so a server recognizes and rejects duplicate processing of the same logical action even if it arrives multiple times.

Idempotency keys work specifically well against the coupon and balance-redemption pattern covered earlier: a unique key attached to each transaction request lets the server confirm whether that exact request has already been processed, rejecting duplicates regardless of how closely spaced the concurrent attempts arrive. This is why payment processors rely on idempotency keys as a standard control rather than an optional add-on, the pattern directly closes the gap OWASP’s Software and Data Integrity Failures category specifically warns against, since a race condition in payment logic represents exactly the kind of integrity failure that category exists to prevent.

Where does an air gap fit into defense against timing attacks?

 Air gaps offer essentially no protection against race conditions specifically, since the vulnerability lives in how a system’s own internal logic handles concurrent, local operations, not in network exposure at all.

Dirty COW and Dirty Pipe both demonstrate this clearly: both are local privilege escalation vulnerabilities, requiring an attacker to already have some level of access to the system, exactly the scenario an air gap is meant to prevent in the first place but doesn’t eliminate once an insider or an already-compromised foothold exists. Treat air gapping as a defense against network-based attack vectors specifically, and treat race condition remediation, atomic operations and proper locking, as an entirely separate, code-level control that an air gap does nothing to substitute for.