Irrelevant code could include dead code, initialization that is not used, empty blocks, code that could be entirely removed due to optimization, etc.
| Impact | Details |
|---|---|
|
Reduce Reliability |
Scope: Other |
|
Reduce Performance |
Scope: Other |
| Nature | Type | ID | Name |
|---|---|---|---|
| ChildOf | Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. | 710 | Improper Adherence to Coding Standards |
| ParentOf | Variant 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. | 107 | Struts: Unused Validation Form |
| ParentOf | Variant 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. | 110 | Struts: Validator Without Form Field |
| ParentOf | Base 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. | 561 | Dead Code |
| ParentOf | Base 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. | 563 | Assignment to Variable without Use |
| ParentOf | Base 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. | 1071 | Empty Code Block |
Example 1
The condition for the second if statement is impossible to satisfy. It requires that the variables be non-null. However, on the only path where s can be assigned a non-null value, there is a return statement.
Example 2
The following code excerpt assigns to the variable r and then overwrites the value without using it.
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 |
|---|---|
|
chain: incorrect "goto" in Apple SSL product bypasses certificate validation, allowing Adversary-in-the-Middle (AITM) attack (Apple "goto fail" bug). CWE-705 (Incorrect Control Flow Scoping) -> CWE-561 (Dead Code) -> CWE-295 (Improper Certificate Validation) -> CWE-393 (Return of Wrong Status Code) -> CWE-300 (Channel Accessible by Non-Endpoint).
|
| Ordinality | Description |
|---|---|
|
Indirect
|
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
|
| Nature | Type | ID | Name |
|---|---|---|---|
| MemberOf | CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. | 1412 | Comprehensive Categorization: Poor Coding Practices |
Rationale
This CWE entry is a Class and might have Base-level children that would be more appropriateComments
Examine children of this entry to see if there is a better fit| Submissions | ||
|---|---|---|
| Submission Date | Submitter | Organization |
|
2019年01月02日
(CWE 3.2, 2019年01月03日) |
CWE Content Team | MITRE |
| Modifications | ||
| Modification Date | Modifier | Organization |
|
2024年02月29日
(CWE 4.14, 2024年02月29日) |
CWE Content Team | MITRE |
| updated Demonstrative_Examples | ||
| 2023年10月26日 | CWE Content Team | MITRE |
| updated Observed_Examples | ||
| 2023年06月29日 | CWE Content Team | MITRE |
| updated Mapping_Notes | ||
| 2023年04月27日 | CWE Content Team | MITRE |
| updated Relationships | ||
| 2023年01月31日 | CWE Content Team | MITRE |
| updated Description | ||
| 2022年04月28日 | CWE Content Team | MITRE |
| updated Relationships | ||
| 2020年02月24日 | CWE Content Team | MITRE |
| updated Relationships | ||
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–2025, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation.