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

ClassDraftExploit Likelihood: Medium

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.

View on MITRE
0Related CVEs
0.00Severity Score
Back to CWE Lookup

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.

Technical Details

Structure
Simple

Applicable To

Languages
CC++Java
Platforms

🏆 CWE Top 25 Historical Ranking

2023:#21
Score: 3.53
412 CVEs
Trend:✗ Dropped from Top 25

Source-backed guidance

Additional facts reviewed against primary or authoritative security sources.

Combine analysis methods around the CWE-362 trust boundary

MITRE identifies black-box testing, white-box review, automated dynamic analysis, binary review as applicable detection approaches. Use them to model shared state, ownership, lock order, atomicity, callbacks, and time-of-check/time-of-use gaps, then force competing operations into the smallest vulnerable interleavings. Require a reproducible trace from the initiating input or state transition to the unsafe behavior, record coverage gaps, and confirm suspected findings dynamically where safe; no single technique establishes complete coverage.

CWE-362: detection methods and operational guidanceMITRE CWE

Protect the complete compound operation with one locking policy

Do not assume a sequence is atomic merely because each called method is independently atomic. Identify the shared state and operations that must be observed as one unit, then protect that complete unit with a consistent locking or synchronization policy. Test concurrent interleavings around reads, checks, and updates, and confirm every participant uses the same policy and lock scope.

CON08-C: Do not assume that a group of calls to independently atomic methods is atomicCarnegie Mellon SEI

Apply lessons from CVE-2025-62215 in Microsoft Windows kernel

NVD maps CVE-2025-62215 to CWE-362; a race condition could allow a local low-privileged attacker to escalate to SYSTEM-level access. Use the case to stress privileged state transitions with concurrent callers, verify object lifetime under contention, and test the repaired synchronization invariant rather than only the original timing.

CVE-2025-62215 DetailNIST National Vulnerability Database

Track CWE-362 as #21 in the 2023 CWE Top 25

CWE-362 ranked #21 in the 2023 CWE Top 25 with a score of 3.53. Use this annual evidence to prioritize systemic prevention, detection coverage, and recurring-root-cause metrics across the portfolio, while retaining asset exposure, exploitability, and business impact for severity decisions on individual findings.

2023 CWE Top 25 Most Dangerous Software WeaknessesMITRE CWE

Stress shared-state interleavings with ThreadSanitizer

Compile supported native targets with ThreadSanitizer and run concurrent create, update, delete, cancellation, signal, and teardown operations repeatedly. Add barriers or scheduler control to widen suspected windows and test both successful and failing paths. Preserve symbolized race reports, then fix the state invariant or synchronization design rather than suppressing a warning solely because the race is difficult to reproduce.

ThreadSanitizerLLVM Project

Frequently Asked Questions

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

CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') is a Common Weakness Enumeration (CWE) entry maintained by MITRE. 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. 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.

Is CWE-362 in the CWE Top 25 Most Dangerous Software Weaknesses?+

Yes. CWE-362 ranked #21 in the CWE Top 25 for 2023, associated with 412 CVEs that year. The CWE Top 25 highlights the most common and impactful software weaknesses based on real-world vulnerability data.

What are the security consequences of Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')?+

If exploited, CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')) it can compromise Availability, Confidentiality, Integrity and Access Control, leading to outcomes such as DoS: Resource Consumption (CPU), DoS: Resource Consumption (Memory), DoS: Resource Consumption (Other), DoS: Crash, Exit, or Restart, DoS: Instability and Read Files or Directories.

How do you prevent or mitigate Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')?+

Recommended mitigations for CWE-362 include: In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance. Use thread-safe capabilities such as the data access abstraction in Spring. 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).

How is Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') detected?+

CWE-362 can be detected using Black Box, White Box, Automated Static Analysis - Binary or Bytecode, Dynamic Analysis with Automated Results Interpretation, Dynamic Analysis with Manual Results Interpretation and Manual Static Analysis - Source Code. Combining automated tooling with manual review typically yields the best coverage.

Which programming languages are affected by Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')?+

CWE-362 commonly affects C, C++ and Java. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.

What are real-world examples of Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')?+

MITRE documents real CVEs mapped to CWE-362, including CVE-2024-38106, CVE-2022-29527, CVE-2021-1782, CVE-2021-0920 and CVE-2020-6819. You can look up the full details of each CVE, including CVSS scores and remediation guidance, on our CVE Lookup tool.

What is the difference between a CWE and a CVE?+

A CWE (Common Weakness Enumeration) like CWE-362 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.

Learn More

Advertisement