CWE - CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') (4.20)

Weakness ID: 362

Vulnerability Mapping: ALLOWED This CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.

View customized information:

For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.

Description

The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.

Extended Description

A race condition occurs within concurrent environments, and it is effectively a property of a code sequence. Depending on the context, a code sequence may be in the form of a function call, a small number of instructions, a series of program invocations, etc.

A race condition violates these properties, which are closely related:

Exclusivity - the code sequence is given exclusive access to the shared resource, i.e., no other code sequence can modify properties of the shared resource before the original sequence has completed execution.
Atomicity - the code sequence is behaviorally atomic, i.e., no other thread or process can concurrently execute the same sequence of instructions (or a subset) against the same resource.

A race condition exists when an "interfering code sequence" can still access the shared resource, violating exclusivity.

The interfering code sequence could be "trusted" or "untrusted." A trusted interfering code sequence occurs within the product; it cannot be modified by the attacker, and it can only be invoked indirectly. An untrusted interfering code sequence can be authored directly by the attacker, and typically it is external to the vulnerable product.

Alternate Terms

Race Condition

Common Consequences

This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

Impact	Details
DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other)	Scope: Availability When a race condition makes it possible to bypass a resource cleanup routine or trigger multiple initialization routines, it may lead to resource exhaustion.
DoS: Crash, Exit, or Restart; DoS: Instability	Scope: Availability When a race condition allows multiple control flows to access a resource simultaneously, it might lead the product(s) into unexpected states, possibly resulting in a crash.
Read Files or Directories; Read Application Data	Scope: Confidentiality, Integrity When a race condition is combined with predictable resource names and loose permissions, it may be possible for an attacker to overwrite or access confidential data (CWE-59).
Execute Unauthorized Code or Commands; Gain Privileges or Assume Identity; Bypass Protection Mechanism	Scope: Access Control This can have security implications when the expected synchronization is in security-critical code, such as recording whether a user is authenticated or modifying important state information that should not be influenced by an outsider.

Potential Mitigations

Phase(s)	Mitigation
Architecture and Design	In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.
Architecture and Design	Use thread-safe capabilities such as the data access abstraction in Spring.
Architecture and Design	Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring. Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).
Implementation	When using multithreading and operating on shared variables, only use thread-safe functions.
Implementation	Use atomic operations on shared variables. Be wary of innocent-looking constructs such as "x++". This may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read, followed by a computation, followed by a write.
Implementation	Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.
Implementation	Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.
Implementation	Disable interrupts or signals over critical parts of the code, but also make sure that the code does not go into a large or infinite loop.
Implementation	Use the volatile type modifier for critical variables to avoid unexpected compiler optimization or reordering. This does not necessarily solve the synchronization problem, but it can help.
Architecture and Design; Operation	Strategy: Environment Hardening Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Relationships

This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

Relevant to the view "Research Concepts" (View-1000)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	662	Improper Synchronization
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	364	Signal Handler Race Condition
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	366	Race Condition within a Thread
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	367	Time-of-check Time-of-use (TOCTOU) Race Condition
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	368	Context Switching Race Condition
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	421	Race Condition During Access to Alternate Channel
ParentOf	Composite - a Compound Element that consists of two or more distinct weaknesses, in which all weaknesses must be present at the same time in order for a potential vulnerability to arise. Removing any of the weaknesses eliminates or sharply reduces the risk. One weakness, X, can be "broken down" into component weaknesses Y and Z. There can be cases in which one weakness might not be essential to a composite, but changes the nature of the composite when it becomes a vulnerability.	689	Permission Race Condition During Resource Copy
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1223	Race Condition for Write-Once Attributes
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1298	Hardware Logic Contains Race Conditions
CanFollow	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	662	Improper Synchronization
CanPrecede	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	416	Use After Free
CanPrecede	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	476	NULL Pointer Dereference

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)

Nature	Type	ID	Name
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1003	Weaknesses for Simplified Mapping of Published Vulnerabilities
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	367	Time-of-check Time-of-use (TOCTOU) Race Condition

Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

Phase	Note
Architecture and Design
Implementation	Programmers may assume that certain code sequences execute too quickly to be affected by an interfering code sequence; when they are not, this violates atomicity. For example, the single "x++" statement may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read (the original value of x), followed by a computation (x+1), followed by a write (save the result to x).

Phase

Note

Architecture and Design

Implementation

Programmers may assume that certain code sequences execute too quickly to be affected by an interfering code sequence; when they are not, this violates atomicity. For example, the single "x++" statement may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read (the original value of x), followed by a computation (x+1), followed by a write (save the result to x).

Applicable Platforms

This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages	C (Sometimes Prevalent) C++ (Sometimes Prevalent) Java (Sometimes Prevalent)
Technologies	Class: Mobile (Undetermined Prevalence) Class: ICS/OT (Undetermined Prevalence)

Likelihood Of Exploit

Medium

Demonstrative Examples

Example 1

This code could be used in an e-commerce application that supports transfers between accounts. It takes the total amount of the transfer, sends it to the new account, and deducts the amount from the original account.

(bad code)

Example Language: Perl

$transfer_amount = GetTransferAmount();
$balance = GetBalanceFromDatabase();

if ($transfer_amount < 0) {

FatalError("Bad Transfer Amount");

}
$newbalance = $balance - $transfer_amount;
if (($balance - $transfer_amount) < 0) {

FatalError("Insufficient Funds");

}
SendNewBalanceToDatabase($newbalance);
NotifyUser("Transfer of $transfer_amount succeeded.");
NotifyUser("New balance: $newbalance");

A race condition could occur between the calls to GetBalanceFromDatabase() and SendNewBalanceToDatabase().

Suppose the balance is initially 100.00. An attack could be constructed as follows:

(attack code)

Example Language: Other

In the following pseudocode, the attacker makes two simultaneous calls of the program, CALLER-1 and CALLER-2. Both callers are for the same user account.
CALLER-1 (the attacker) is associated with PROGRAM-1 (the instance that handles CALLER-1). CALLER-2 is associated with PROGRAM-2.
CALLER-1 makes a transfer request of 80.00.
PROGRAM-1 calls GetBalanceFromDatabase and sets $balance to 100.00
PROGRAM-1 calculates $newbalance as 20.00, then calls SendNewBalanceToDatabase().
Due to high server load, the PROGRAM-1 call to SendNewBalanceToDatabase() encounters a delay.
CALLER-2 makes a transfer request of 1.00.
PROGRAM-2 calls GetBalanceFromDatabase() and sets $balance to 100.00. This happens because the previous PROGRAM-1 request was not processed yet.
PROGRAM-2 determines the new balance as 99.00.
After the initial delay, PROGRAM-1 commits its balance to the database, setting it to 20.00.
PROGRAM-2 sends a request to update the database, setting the balance to 99.00

At this stage, the attacker should have a balance of 19.00 (due to 81.00 worth of transfers), but the balance is 99.00, as recorded in the database.

To prevent this weakness, the programmer has several options, including using a lock to prevent multiple simultaneous requests to the web application, or using a synchronization mechanism that includes all the code between GetBalanceFromDatabase() and SendNewBalanceToDatabase().

Example 2

The following function attempts to acquire a lock in order to perform operations on a shared resource.

(bad code)

Example Language: C

void f(pthread_mutex_t *mutex) {

pthread_mutex_lock(mutex);

/* access shared resource */

pthread_mutex_unlock(mutex);

}

However, the code does not check the value returned by pthread_mutex_lock() for errors. If pthread_mutex_lock() cannot acquire the mutex for any reason, the function may introduce a race condition into the program and result in undefined behavior.

In order to avoid data races, correctly written programs must check the result of thread synchronization functions and appropriately handle all errors, either by attempting to recover from them or reporting them to higher levels.

(good code)

Example Language: C

int f(pthread_mutex_t *mutex) {

int result;

result = pthread_mutex_lock(mutex);
if (0 != result)

return result;

/* access shared resource */

return pthread_mutex_unlock(mutex);

}

Example 3

Suppose a processor's Memory Management Unit (MMU) has 5 other shadow MMUs to distribute its workload for its various cores. Each MMU has the start address and end address of "accessible" memory. Any time this accessible range changes (as per the processor's boot status), the main MMU sends an update message to all the shadow MMUs.

Suppose the interconnect fabric does not prioritize such "update" packets over other general traffic packets. This introduces a race condition. If an attacker can flood the target with enough messages so that some of those attack packets reach the target before the new access ranges gets updated, then the attacker can leverage this scenario.

Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference	Description
CVE-2024-38106	OS kernel stores sensitive data in improperly locked memory, allowing local users to gain privileges by winning a race condition
CVE-2022-29527	Go application for cloud management creates a world-writable sudoers file that allows local attackers to inject sudo rules and escalate privileges to root by winning a race condition.
CVE-2021-1782	Chain: improper locking (CWE-667) leads to race condition (CWE-362), as exploited in the wild per CISA KEV.
CVE-2021-0920	Chain: mobile platform race condition (CWE-362) leading to use-after-free (CWE-416), as exploited in the wild per CISA KEV.
CVE-2020-6819	Chain: race condition (CWE-362) leads to use-after-free (CWE-416), as exploited in the wild per CISA KEV.
CVE-2019-18827	chain: JTAG interface is not disabled (CWE-1191) during ROM code execution, introducing a race condition (CWE-362) to extract encryption keys
CVE-2019-1161	Chain: race condition (CWE-362) in anti-malware product allows deletion of files by creating a junction (CWE-1386) and using hard links during the time window in which a temporary file is created and deleted.
CVE-2015-1743	TOCTOU in sandbox process allows installation of untrusted browser add-ons by replacing a file after it has been verified, but before it is executed
CVE-2014-8273	Chain: chipset has a race condition (CWE-362) between when an interrupt handler detects an attempt to write-enable the BIOS (in violation of the lock bit), and when the handler resets the write-enable bit back to 0, allowing attackers to issue BIOS writes during the timing window [REF-1237].
CVE-2008-5044	Race condition leading to a crash by calling a hook removal procedure while other activities are occurring at the same time.
CVE-2008-2958	chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
CVE-2008-1570	chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
CVE-2008-0058	Unsynchronized caching operation enables a race condition that causes messages to be sent to a deallocated object.
CVE-2008-0379	Race condition during initialization triggers a buffer overflow.
CVE-2007-6599	Daemon crash by quickly performing operations and undoing them, which eventually leads to an operation that does not acquire a lock.
CVE-2007-6180	chain: race condition triggers NULL pointer dereference
CVE-2007-5794	Race condition in library function could cause data to be sent to the wrong process.
CVE-2007-3970	Race condition in file parser leads to heap corruption.
CVE-2008-5021	chain: race condition allows attacker to access an object while it is still being initialized, causing software to access uninitialized memory.
CVE-2009-4895	chain: race condition for an argument value, possibly resulting in NULL dereference
CVE-2009-3547	Chain: race condition (CWE-362) might allow resource to be released before operating on it, leading to NULL dereference (CWE-476)
CVE-2006-5051	Chain: Signal handler contains too much functionality (CWE-828), introducing a race condition (CWE-362) that leads to a double free (CWE-415).

Weakness Ordinalities

Ordinality	Description
Primary	(where the weakness exists independent of other weaknesses)
Resultant	(where the weakness is typically related to the presence of some other weaknesses)

Detection Methods

Method	Details
Black Box	Black box methods may be able to identify evidence of race conditions via methods such as multiple simultaneous connections, which may cause the software to become instable or crash. However, race conditions with very narrow timing windows would not be detectable.
White Box	Common idioms are detectable in white box analysis, such as time-of-check-time-of-use (TOCTOU) file operations (CWE-367), or double-checked locking (CWE-609).
Automated Dynamic Analysis	This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results. Race conditions may be detected with a stress-test by calling the software simultaneously from a large number of threads or processes, and look for evidence of any unexpected behavior. Insert breakpoints or delays in between relevant code statements to artificially expand the race window so that it will be easier to detect. Effectiveness: Moderate
Automated Static Analysis - Binary or Bytecode	According to SOAR [REF-1479], the following detection techniques may be useful: Highly cost effective: Bytecode Weakness Analysis - including disassembler + source code weakness analysis Cost effective for partial coverage: Binary Weakness Analysis - including disassembler + source code weakness analysis Effectiveness: High
Dynamic Analysis with Automated Results Interpretation	According to SOAR [REF-1479], the following detection techniques may be useful: Cost effective for partial coverage: Web Application Scanner Web Services Scanner Database Scanners Effectiveness: SOAR Partial
Dynamic Analysis with Manual Results Interpretation	According to SOAR [REF-1479], the following detection techniques may be useful: Highly cost effective: Framework-based Fuzzer Cost effective for partial coverage: Fuzz Tester Monitored Virtual Environment - run potentially malicious code in sandbox / wrapper / virtual machine, see if it does anything suspicious Effectiveness: High
Manual Static Analysis - Source Code	According to SOAR [REF-1479], the following detection techniques may be useful: Highly cost effective: Manual Source Code Review (not inspections) Cost effective for partial coverage: Focused Manual Spotcheck - Focused manual analysis of source Effectiveness: High
Automated Static Analysis - Source Code	According to SOAR [REF-1479], the following detection techniques may be useful: Highly cost effective: Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer Effectiveness: High
Architecture or Design Review	According to SOAR [REF-1479], the following detection techniques may be useful: Highly cost effective: Formal Methods / Correct-By-Construction Cost effective for partial coverage: Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.) Effectiveness: High

Affected Resources

File or Directory

Memberships

This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.

Nature	Type	ID	Name
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	635	Weaknesses Originally Used by NVD from 2008 to 2016
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	743	CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	751	2009 Top 25 - Insecure Interaction Between Components
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	801	2010 Top 25 - Insecure Interaction Between Components
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	852	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - Visibility and Atomicity (VNA)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	867	2011 Top 25 - Weaknesses On the Cusp
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	877	CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	882	CERT C++ Secure Coding Section 14 - Concurrency (CON)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	988	SFP Secondary Cluster: Race Condition Window
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1142	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 08. Visibility and Atomicity (VNA)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1364	ICS Communications: Zone Boundary Failures
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1365	ICS Communications: Unreliability
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1366	ICS Communications: Frail Security in Protocols
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1376	ICS Engineering (Construction/Deployment): Security Gaps in Commissioning
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1387	Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1401	Comprehensive Categorization: Concurrency
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1425	Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1441	OWASP Top Ten 2025 Category A06:2025 - Insecure Design

Vulnerability Mapping Notes

Usage	ALLOWED-WITH-REVIEW (this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)
Reason	Abstraction
Rationale	This CWE entry is a Class and might have Base-level children that would be more appropriate
Comments	Examine children of this entry to see if there is a better fit

Notes

Research Gap

Race conditions in web applications are under-studied and probably under-reported. However, in 2008 there has been growing interest in this area.

Research Gap

Much of the focus of race condition research has been in Time-of-check Time-of-use (TOCTOU) variants (CWE-367), but many race conditions are related to synchronization problems that do not necessarily require a time-of-check.

Research Gap

From a classification/taxonomy perspective, the relationships between concurrency and program state need closer investigation and may be useful in organizing related issues.

Maintenance

The relationship between race conditions and synchronization problems (CWE-662) needs to be further developed. They are not necessarily two perspectives of the same core concept, since synchronization is only one technique for avoiding race conditions, and synchronization can be used for other purposes besides race condition prevention.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
PLOVER			Race Conditions
The CERT Oracle Secure Coding Standard for Java (2011)	VNA03-J		Do not assume that a group of calls to independently atomic methods is atomic

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-26	Leveraging Race Conditions
CAPEC-29	Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions

References

[REF-44]	Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 13: Race Conditions." Page 205. McGraw-Hill. 2010.
[REF-349]	Andrei Alexandrescu. "volatile - Multithreaded Programmer's Best Friend". Dr. Dobb's. 2008-02-01. <https://drdobbs.com/cpp/volatile-the-multithreaded-programmers-b/184403766>. (URL validated: 2023-04-07)
[REF-350]	Steven Devijver. "Thread-safe webapps using Spring". <https://web.archive.org/web/20170609174845/http://www.javalobby.org/articles/thread-safe/index.jsp>. (URL validated: 2023-04-07)
[REF-351]	David Wheeler. "Prevent race conditions". 2007-10-04. <https://www.ida.liu.se/~TDDC90/literature/papers/SP-race-conditions.pdf>. (URL validated: 2023-04-07)
[REF-352]	Matt Bishop. "Race Conditions, Files, and Security Flaws; or the Tortoise and the Hare Redux". 1995-09. <https://seclab.cs.ucdavis.edu/projects/vulnerabilities/scriv/ucd-ecs-95-08.pdf>. (URL validated: 2023-04-07)
[REF-353]	David Wheeler. "Secure Programming for Linux and Unix HOWTO". 2003-03-03. <https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html>. (URL validated: 2023-04-07)
[REF-354]	Blake Watts. "Discovering and Exploiting Named Pipe Security Flaws for Fun and Profit". 2002-04. <https://www.blakewatts.com/blog/discovering-and-exploiting-named-pipe-security-flaws-for-fun-and-profit>. (URL validated: 2023-04-07)
[REF-355]	Roberto Paleari, Davide Marrone, Danilo Bruschi and Mattia Monga. "On Race Vulnerabilities in Web Applications". <http://security.dico.unimi.it/~roberto/pubs/dimva08-web.pdf>.
[REF-356]	"Avoiding Race Conditions and Insecure File Operations". Apple Developer Connection. <https://web.archive.org/web/20081010155022/http://developer.apple.com/documentation/Security/Conceptual/SecureCodingGuide/Articles/RaceConditions.html>. (URL validated: 2023-04-07)
[REF-357]	Johannes Ullrich. "Top 25 Series - Rank 25 - Race Conditions". SANS Software Security Institute. 2010-03-26. <https://web.archive.org/web/20100530231203/http://blogs.sans.org:80/appsecstreetfighter/2010/03/26/top-25-series-rank-25-race-conditions/>. (URL validated: 2023-04-07)
[REF-76]	Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://web.archive.org/web/20211209014121/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege>. (URL validated: 2023-04-07)
[REF-1237]	CERT Coordination Center. "Intel BIOS locking mechanism contains race condition that enables write protection bypass". 2015-01-05. <https://www.kb.cert.org/vuls/id/766164/>.
[REF-1479]	Gregory Larsen, E. Kenneth Hong Fong, David A. Wheeler and Rama S. Moorthy. "State-of-the-Art Resources (SOAR) for Software Vulnerability Detection, Test, and Evaluation". 2014-07. <https://www.ida.org/-/media/feature/publications/s/st/stateoftheart-resources-soar-for-software-vulnerability-detection-test-and-evaluation/p-5061.ashx>. (URL validated: 2025-09-05)

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	PLOVER
2006-07-19 (CWE Draft 3, 2006-07-19)
Contributions
Contribution Date	Contributor	Organization
2024-02-29 (CWE 4.16, 2024-11-19)	Abhi Balakrishnan
2024-02-29 (CWE 4.16, 2024-11-19)	Provided diagram to improve CWE usability
2010-04-30	Martin Sebor	Cisco Systems, Inc.
2010-04-30	Provided Demonstrative Example
Modifications
Modification Date	Modifier	Organization
2026-04-30 (CWE 4.20, 2026-04-30)	CWE Content Team	MITRE
2026-04-30 (CWE 4.20, 2026-04-30)	updated Observed_Examples
2025-12-11 (CWE 4.19, 2025-12-11)	CWE Content Team	MITRE
2025-12-11 (CWE 4.19, 2025-12-11)	updated Observed_Examples, Relationships, Weakness_Ordinalities
2025-09-09 (CWE 4.18, 2025-09-09)	CWE Content Team	MITRE
2025-09-09 (CWE 4.18, 2025-09-09)	updated Detection_Factors, References
2025-04-03 (CWE 4.17, 2025-04-03)	CWE Content Team	MITRE
2025-04-03 (CWE 4.17, 2025-04-03)	updated Affected_Resources
2024-11-19 (CWE 4.16, 2024-11-19)	CWE Content Team	MITRE
2024-11-19 (CWE 4.16, 2024-11-19)	updated Alternate_Terms, Common_Consequences, Description, Diagram, Modes_of_Introduction
2024-07-16 (CWE 4.15, 2024-07-16)	CWE Content Team	MITRE
2024-07-16 (CWE 4.15, 2024-07-16)	updated Relationships
2023-06-29 (CWE 4.12, 2023-06-29)	CWE Content Team	MITRE
2023-06-29 (CWE 4.12, 2023-06-29)	updated Mapping_Notes, Relationships
2023-04-27 (CWE 4.11, 2023-04-27)	CWE Content Team	MITRE
2023-04-27 (CWE 4.11, 2023-04-27)	updated References, Relationships
2023-01-31 (CWE 4.10, 2023-01-31)	CWE Content Team	MITRE
2023-01-31 (CWE 4.10, 2023-01-31)	updated Applicable_Platforms, Common_Consequences, Description
2022-10-13 (CWE 4.9, 2022-10-13)	CWE Content Team	MITRE
2022-10-13 (CWE 4.9, 2022-10-13)	updated Observed_Examples, References
2022-06-28 (CWE 4.8, 2022-06-28)	CWE Content Team	MITRE
2022-06-28 (CWE 4.8, 2022-06-28)	updated Observed_Examples, Relationships
2022-04-28 (CWE 4.7, 2022-04-28)	CWE Content Team	MITRE
2022-04-28 (CWE 4.7, 2022-04-28)	updated Observed_Examples, Relationships
2021-10-28 (CWE 4.6, 2021-10-28)	CWE Content Team	MITRE
2021-10-28 (CWE 4.6, 2021-10-28)	updated Observed_Examples, References
2021-03-15 (CWE 4.4, 2021-03-15)	CWE Content Team	MITRE
2021-03-15 (CWE 4.4, 2021-03-15)	updated Demonstrative_Examples
2020-08-20 (CWE 4.2, 2020-08-20)	CWE Content Team	MITRE
2020-08-20 (CWE 4.2, 2020-08-20)	updated Relationships
2020-02-24 (CWE 4.0, 2020-02-24)	CWE Content Team	MITRE
2020-02-24 (CWE 4.0, 2020-02-24)	updated Applicable_Platforms, Demonstrative_Examples, Observed_Examples, Relationships
2019-06-20 (CWE 3.3, 2019-06-20)	CWE Content Team	MITRE
2019-06-20 (CWE 3.3, 2019-06-20)	updated Relationships
2019-01-03 (CWE 3.2, 2019-01-03)	CWE Content Team	MITRE
2019-01-03 (CWE 3.2, 2019-01-03)	updated Relationships, Taxonomy_Mappings
2017-11-08 (CWE 3.0, 2017-11-08)	CWE Content Team	MITRE
2017-11-08 (CWE 3.0, 2017-11-08)	updated Demonstrative_Examples, References, Research_Gaps, Taxonomy_Mappings
2015-12-07 (CWE 2.9, 2015-12-07)	CWE Content Team	MITRE
2015-12-07 (CWE 2.9, 2015-12-07)	updated Relationships
2014-07-30 (CWE 2.8, 2014-07-31)	CWE Content Team	MITRE
2014-07-30 (CWE 2.8, 2014-07-31)	updated Detection_Factors, Relationships
2012-05-11 (CWE 2.2, 2012-05-15)	CWE Content Team	MITRE
2012-05-11 (CWE 2.2, 2012-05-15)	updated Potential_Mitigations, References, Relationships
2011-09-13 (CWE 2.1, 2011-09-13)	CWE Content Team	MITRE
2011-09-13 (CWE 2.1, 2011-09-13)	updated Relationships, Taxonomy_Mappings
2011-06-27 (CWE 2.0, 2011-06-27)	CWE Content Team	MITRE
2011-06-27 (CWE 2.0, 2011-06-27)	updated Relationships
2011-06-01 (CWE 1.13, 2011-06-01)	CWE Content Team	MITRE
2011-06-01 (CWE 1.13, 2011-06-01)	updated Common_Consequences, Relationships, Taxonomy_Mappings
2010-12-13 (CWE 1.11, 2010-12-13)	CWE Content Team	MITRE
2010-12-13 (CWE 1.11, 2010-12-13)	updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Potential_Mitigations, Relationships
2010-09-27 (CWE 1.10, 2010-09-27)	CWE Content Team	MITRE
2010-09-27 (CWE 1.10, 2010-09-27)	updated Observed_Examples, Potential_Mitigations, Relationships
2010-06-21 (CWE 1.9, 2010-06-21)	CWE Content Team	MITRE
2010-06-21 (CWE 1.9, 2010-06-21)	updated Common_Consequences, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References
2010-02-16 (CWE 1.8, 2010-02-16)	CWE Content Team	MITRE
2010-02-16 (CWE 1.8, 2010-02-16)	updated Detection_Factors, References, Relationships
2009-05-27 (CWE 1.4, 2009-05-27)	CWE Content Team	MITRE
2009-05-27 (CWE 1.4, 2009-05-27)	updated Relationships
2009-03-10 (CWE 1.3, 2009-03-10)	CWE Content Team	MITRE
2009-03-10 (CWE 1.3, 2009-03-10)	updated Demonstrative_Examples, Potential_Mitigations
2009-01-12 (CWE 1.2, 2009-01-12)	CWE Content Team	MITRE
2009-01-12 (CWE 1.2, 2009-01-12)	updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Maintenance_Notes, Observed_Examples, Potential_Mitigations, References, Relationships, Research_Gaps
2008-11-24 (CWE 1.1, 2008-11-25)	CWE Content Team	MITRE
2008-11-24 (CWE 1.1, 2008-11-25)	updated Relationships, Taxonomy_Mappings
2008-10-14 (CWE 1.0.1, 2008-10-14)	CWE Content Team	MITRE
2008-10-14 (CWE 1.0.1, 2008-10-14)	updated Relationships
2008-09-08 (CWE 1.0, 2008-09-09)	CWE Content Team	MITRE
2008-09-08 (CWE 1.0, 2008-09-09)	updated Relationships, Taxonomy_Mappings
2008-07-01 (CWE 1.0, 2008-09-09)	Eric Dalci	Cigital
2008-07-01 (CWE 1.0, 2008-09-09)	updated Time_of_Introduction
Previous Entry Names
Change Date	Previous Entry Name
2010-12-13	Race Condition
2008-04-11	Race Conditions

CWE Glossary Definition


	Site Map \| Terms of Use \| Manage Cookies \| Cookie Notice \| Privacy Policy \| Contact Us \| Use of the Common Weakness Enumeration (CWE™) and the associated references from this website are subject to the Terms of Use. CWE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). Copyright © 2006–2026, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation.

Common Weakness Enumeration

CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

Edit Custom Filter