Attackers use Leveraging Race Conditions by timing requests so security checks and state changes happen out of order, allowing duplicate actions, privilege changes, or unauthorised access. Defenders should make critical operations atomic, add server-side locking or transaction controls, and test for concurrent request handling under load.
How race conditions become an attack path
Race conditions matter because the attacker is not breaking a control directly, they are exploiting timing. If a system checks one state, then changes another state later, a second request can slip into the gap and get treated as valid. That can turn a normal workflow into duplicate execution, unauthorised state changes, or a bypass of a security decision.
What makes this useful to attackers is that the weakness often appears only under concurrency, load, or retry behaviour. A flow that looks safe in single-request testing may fail when two requests arrive together, or when a client repeats a request faster than the server finishes updating state.
Many race issues map to classic software weakness patterns such as CWE Top 25 Guide, especially where time-of-check and time-of-use are separated across multiple operations. In practice, the security flaw is not the request itself, but the fact that the application treats an intermediate state as trustworthy.
What attackers try to gain from timing windows
Attackers usually look for actions that have value when repeated or reordered, such as account changes, payment steps, token use, entitlement updates, or object creation. If the server accepts two nearly simultaneous requests, both can pass a check that was meant to be exclusive, which can produce duplicate transactions or a state the business logic never intended.
In higher-impact cases, the same pattern can let an attacker race a privilege change, bypass a one-time constraint, or trigger an action before revocation or validation takes effect. That is why race conditions are often discussed alongside broader weakness categories in CWE Top 25 Guide, and why defenders should think in terms of atomicity rather than only input validation.
Attackers often prefer race flaws because they are efficient and difficult to see in logs if the application does not record the competing requests or the state transitions between them. A successful race can look like ordinary user behaviour unless the server captures ordering, correlation, and transaction boundaries.
How defenders should close the gap
The most reliable fix is to make the security-sensitive operation atomic so the check and the state change cannot be separated by another request. Server-side locking, transactional integrity, unique constraints, idempotency handling, and strict state-machine enforcement are the usual controls that remove the exploitable gap.
Testing should also reflect the attack method, not just the happy path. Concurrency tests, stress tests, and repeated-request simulations are important because a race condition can remain invisible until the system is under load or until two actors compete for the same resource at the same time.
For teams that want a broader weakness taxonomy and a common vocabulary for this class of bug, CWE Top 25 Guide is the right starting point for mapping race patterns to secure coding and review priorities.
Risk and Threat Considerations
Race conditions are dangerous because the failure is probabilistic: the same workflow may be safe most of the time and exploitable only when timing aligns. That makes them attractive for attackers and hard for defenders to reproduce, especially in distributed systems, high-latency environments, or workflows with retries and asynchronous state changes.
Failure mechanism: Two requests compete against the same resource or decision point, and the system validates one state before it has finished committing the next state, allowing duplicate execution or an unauthorised transition.
Impact: The result can be duplicate actions, privilege escalation, unauthorised access, corrupted records, or irreversible business-process abuse, especially where the action is high value or the state change cannot be cleanly rolled back.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, CIS Controls v8, OWASP ASVS and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-16 — Application Software Security | Race conditions are secure coding flaws that require testing and remediation in software workflows. |
| Recommendation — Test concurrent paths and remediate race-prone workflows before release. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Concurrency and atomicity failures are application architecture and secure coding concerns. |
| Recommendation — Design critical state changes to be atomic and resistant to parallel requests. | ||
| NIST SP 800-53 Rev 5 | SC-39 — Process Isolation | Race exploitation depends on separating competing operations so one can interfere with another. |
| Recommendation — Isolate sensitive processes and enforce exclusive control over critical operations. | ||
| MITRE ATT&CK | T1209 — Process Injection | The attack pattern involves exploiting execution timing and process interaction to alter outcomes. |
| Recommendation — Map timing abuse to attack-path detection and hunt for abnormal concurrent execution. | ||
| ISO/IEC 27001:2022 | A.8.26 — Application security requirements | Application security requirements must address timing-related weakness in sensitive workflows. |
| Recommendation — Specify concurrency and atomicity requirements for security-sensitive application functions. | ||
Practitioner Guidance
What to verify: Confirm that the sensitive operation is protected end-to-end, not just that a single function performs a check. The important question is whether two concurrent requests can both reach the trust decision before the first one commits the state change.
Decision rule: If the action changes privilege, ownership, or financial or security state, treat optimistic assumptions as unsafe unless the server enforces atomicity or a hard uniqueness constraint. If the outcome is merely cosmetic, the control bar can be lower.
What practitioners underestimate: The bug is often in the workflow, not in one line of code. A secure-looking validation step can still fail if the request can be replayed, retried, or parallelised before the authoritative state is updated.
Practitioner takeaway: Treat timing as part of the attack surface. If a user can benefit from two requests arriving in the wrong order, the workflow is not yet secure enough.