The source code contains a block that does not contain any code, i.e., the block is empty.
View on MITREEmpty code blocks can occur in the bodies of conditionals, function or method definitions, exception handlers, etc. While an empty code block might be intentional, it might also indicate incomplete implementation, accidental code deletion, unexpected macro expansion, etc. For some programming languages and constructs, an empty block might be allowed by the syntax, but the lack of any behavior within the block might violate a convention or API in such a way that it is an error.
No mitigation information available for this CWE.
No detection method information available for this CWE.
In the following Java example, the code catches an ArithmeticException.
Since the exception block is empty, no action is taken.
public class Main { public static void main(String[] args) { int a = 1; int b = 0; int c = 0; try { c = a / b; } catch(ArithmeticException ae) { } } }In the following Java example, the code catches an ArithmeticException.
Since the exception block is empty, no action is taken.
public class Main { public static void main(String[] args) { int a = 1; int b = 0; int c = 0; try { c = a / b; } catch(ArithmeticException ae) { log.error("Divided by zero detected, setting to -1."); c = -1; } } }The following code attempts to synchronize on an object, but does not execute anything in the synchronized block. This does not actually accomplish anything and may be a sign that a programmer is wrestling with synchronization but has not yet achieved the result they intend.
Instead, in a correct usage, the synchronized statement should contain procedures that access or modify data that is exposed to multiple threads. For example, consider a scenario in which several threads are accessing student records at the same time. The method which sets the student ID to a new value will need to make sure that nobody else is accessing this data at the same time and will require synchronization.
synchronized(this) { }The following code attempts to synchronize on an object, but does not execute anything in the synchronized block. This does not actually accomplish anything and may be a sign that a programmer is wrestling with synchronization but has not yet achieved the result they intend.
Instead, in a correct usage, the synchronized statement should contain procedures that access or modify data that is exposed to multiple threads. For example, consider a scenario in which several threads are accessing student records at the same time. The method which sets the student ID to a new value will need to make sure that nobody else is accessing this data at the same time and will require synchronization.
public void setID(int ID){synchronized(this){this.ID = ID;}}Additional facts reviewed against primary or authoritative security sources.
Documented detection approaches include Automated Static Analysis; recorded impacts include Reduce Reliability; related weaknesses include CWE-1164. Use these source-defined anchors to turn CWE-1071 into implementation, review, and verification checks for the affected component.
CWE-1071: Empty Code Block — MITRE CWEUse NIST SSDF practices to make prevention of CWE-1071, Empty Code Block, an explicit development outcome. Translate the CWE definition into security requirements and design constraints, choose safer implementation patterns and toolchain checks, and define acceptance evidence before release. Feed every confirmed occurrence back into the requirements, design review, and coding rules so the same root cause is removed across the product rather than patched in one location.
NIST SP 800-218 Secure Software Development Framework — National Institute of Standards and TechnologyUse CISA's Known Exploited Vulnerabilities catalog to test whether a vulnerability mapped to CWE-1071, Empty Code Block, has evidence of exploitation in the wild. Confirm the CVE-to-CWE root-cause mapping independently before attaching the example, then capture the affected product, required action, and remediation deadline. A missing KEV match is not evidence that the weakness is unexploited, and a KEV entry must not be generalized to every occurrence of this CWE.
Known Exploited Vulnerabilities Catalog — Cybersecurity and Infrastructure Security AgencyApply MITRE's full root-cause mapping guidance when using CWE-1071, Empty Code Block. Separate weakness language from attacker prerequisites and technical impact, check the entry's abstraction and vulnerability-mapping notes, and prefer the most specific Base or Variant supported by the evidence. Record the rejected alternatives and require an independent review before the mapping is used for remediation trends or program metrics.
CVE to CWE Root Cause Mapping Guidance — MITRE CWEApply MITRE's root-cause mapping quick tips to CWE-1071, Empty Code Block. Confirm the finding describes the causal weakness rather than an impact or attack pattern, compare the abstraction and mapping notes with plausible alternatives, and have a second reviewer challenge the selection. Preserve the evidence and reasoning so recurring defects can be measured against one consistent identifier.
CVE to CWE Root Cause Mapping Quick Tips — MITRE CWECWE-1071: Empty Code Block is a Common Weakness Enumeration (CWE) entry maintained by MITRE. The source code contains a block that does not contain any code, i.e., the block is empty. Empty code blocks can occur in the bodies of conditionals, function or method definitions, exception handlers, etc. While an empty code block might be intentional, it might also indicate incomplete implementation, accidental code deletion, unexpected macro expansion, etc. For some programming languages and constructs, an empty block might be allowed by the syntax, but the lack of any behavior within the block might violate a convention or API in such a way that it is an error.
If exploited, CWE-1071 (Empty Code Block) it can compromise Other, leading to outcomes such as Reduce Reliability.
CWE-1071 commonly affects Not Language-Specific. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.
A CWE (Common Weakness Enumeration) like CWE-1071 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.