CWE-570: Expression is Always False
The product contains an expression that will always evaluate to false.
Last updated
Overview
CWE-570 (Expression is Always False) is a base-level software weakness catalogued by MITRE in the Common Weakness Enumeration (CWE). It describes a recurring type of mistake that can lead to exploitable security vulnerabilities.
Real-world CVEs
1 recorded CVEs are caused by CWE-570 (Expression is Always False). The highest-severity and most recent are shown first.
Common consequences
What can happen when CWE-570 is exploited.
Quality Degradation, Varies by Context
Affects: Other
How it happens
When it is introduced
Typically introduced during these phases of the software lifecycle.
How to prevent it
Practical mitigations for CWE-570, grouped by where in the lifecycle they apply.
Consider refactoring the code, or determine if the code is not including a condition that could cause the expression to become false.
How to detect it
Automated Static Analysis
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Effectiveness: High
Code examples
Illustrative examples from MITRE showing how the weakness appears in code.
In the following Java example the updateUserAccountOrder() method used within an e-business product ordering/inventory application will validate the product number that was ordered and the user account number. If they are valid, the method will update the product inventory, the user account, and the user order appropriately.
In the following example, the hasReadWriteAccess method uses bit masks and bit operators to determine if a user has read and write privileges for a particular process. The variable mask is defined as a bit mask from the BIT_READ and BIT_WRITE constants that have been defined. The variable mask is used within the predicate of the hasReadWriteAccess method to determine if the userMask input parameter has the read and write bits set.
Vulnerable example
#define BIT_READ 0x0001 // 00000001In the following example, the updateInventory method used within an e-business inventory application will update the inventory for a particular product. This method includes an if statement with an expression that will always evaluate to false. This is a common practice in C/C++ to introduce debugging statements quickly by simply changing the expression to evaluate to true and then removing those debugging statements by changing expression to evaluate to false. This is also a common practice for disabling features no longer needed.
Vulnerable example
int updateInventory(char* productNumber, int numberOfItems) {Using this practice for introducing debugging statements or disabling features creates dead code that can cause problems during code maintenance and potentially introduce vulnerabilities. To avoid using expressions that evaluate to false for debugging purposes a logging API or debugging API should be used for the output of debugging messages.
Terminology & mappings
Mapped taxonomies
- CERT C Secure Coding: Compile cleanly at high warning levels (MSC00-C)
- Software Fault Patterns: Glitch in computation (SFP1)
Frequently asked questions
Common questions about CWE-570.
- What is CWE-570?
- The product contains an expression that will always evaluate to false.
- What CVEs are caused by CWE-570?
- 1 recorded CVEs are attributed to CWE-570, including CVE-2024-32633.
- How do you prevent CWE-570?
- Consider refactoring the code, or determine if the code is not including a condition that could cause the expression to become false.
- How is CWE-570 detected?
- Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
- What are the consequences of CWE-570?
- Exploiting CWE-570 can lead to: Quality Degradation, Varies by Context.
- Is CWE-570 actively exploited?
- 1 recorded CVEs are caused by CWE-570; none are currently in CISA's KEV catalog of actively exploited flaws.
References
- MITRE CWE definition (CWE-570) (opens in a new tab)
- CWE-570 vulnerabilities on NVD (opens in a new tab)
- Learn: What is a CWE?
Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.
Stay ahead of CWE-570
Get alerted the moment a new CWE-570 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.