A race condition is a flaw in which the result of a program depends on the timing of concurrent operations, allowing an attacker to slip in between a check and the action that relies on it.
How race conditions work
Modern software does many things in parallel: threads, processes and requests share files, memory and database records. If the code first checks something and then acts on it in two separate steps, the state may change in between. This classic pattern is called time-of-check to time-of-use (TOCTOU, CWE-367); the general weakness is CWE-362.
Examples:
- A privileged program checks that a file is safe and then opens it, but an attacker swaps the file for a symbolic link to a system file in the meantime.
- A web shop checks that a gift card has not been used and then redeems it; sending many requests at the same moment redeems it several times (“limit overrun”).
- In the kernel, two threads free or modify the same object, causing memory corruption such as use-after-free.
Why race conditions matter
Race conditions are hard to find in testing because they appear only with specific timing, yet attackers can trigger them reliably by repeating attempts. The Dirty COW bug in the Linux kernel (CVE-2016-5195) let any local user gain root via a race in memory handling and was exploited in the wild, including on Android. Many local privilege escalation vulnerabilities in Windows and Linux are race conditions, and in web applications they enable financial fraud. Together with buffer overflows, they belong to the most technical classes of bugs.
How to prevent race conditions
- Use atomic operations, locks and database transactions with proper constraints.
- Avoid separate check-then-use steps on files; operate on file handles instead of paths.
- Make sensitive web operations idempotent and rate-limited.
- Test with concurrency tools, fuzzers and thread sanitizers.
