CWE-570 describes an expression that always evaluates to false. The branch it guards can never execute.
That is a close cousin of dead code, and it carries the same warning. The developer wrote the condition because they expected it to sometimes be true. If it never is, either the logic is wrong or the guarded code is useless. When the guarded code is a security check, a cleanup step or an error path, the program quietly skips something important.
MITRE lists the weakness as not language specific, with a consequence of quality degradation that varies by context.
How it happens
Typical sources:
- Contradictory conditions.
x > 10 && x < 5. - Wrong operators. Using
&&where||was meant, so two mutually exclusive tests are joined. - Comparing the wrong things. Comparing an unsigned value to less than zero, or comparing a value to itself.
- State that never changes. A flag that is assigned once and always the same.
MITRE's example uses a Java order update where two validity flags are checked together, and the logic means the update path is never taken in the way the author intended. A simplified version:
// Vulnerable pattern: isValidProduct and isValidAccount are never both true
boolean isValidProduct = false;
boolean isValidAccount = false;
if (isValidProduct(productNumber)) {
isValidProduct = true;
} else if (isValidAccount(accountNumber)) {
isValidAccount = true; // only one flag can be set
}
if (isValidProduct && isValidAccount) { // always false
updateInventory();
updateAccount();
}
Because of the else if, only one flag can ever be set, so the final condition cannot be true and nothing is ever updated.
What an attacker gains
MITRE gives no direct attacker benefit, only quality degradation. The security impact comes from what the unreachable branch was meant to do. A skipped validation, audit entry or lockout step weakens the system even though no exploit is needed.
How to find it
MITRE says automated static analysis can find some instances. Compilers and linters flag constant conditions and impossible comparisons. Branch coverage reports are useful too: a branch with zero hits across a thorough test suite deserves a look.
How to fix it
MITRE's mitigation, under the refactoring strategy: consider refactoring the code, or determine whether the code is missing a condition that could cause the expression to become false... or in this case, true.
Step by step:
- Work out what the author intended the condition to mean.
- Fix the logic so both outcomes are possible, and write tests for each.
- If the branch is truly unnecessary, remove it.
- Keep the "constant condition" warnings on.
// Fixed: both checks run independently
boolean isValidProduct = isValidProduct(productNumber);
boolean isValidAccount = isValidAccount(accountNumber);
if (isValidProduct && isValidAccount) {
updateInventory();
updateAccount();
}
The free in-browser scan at gold.safeguard.sh/scan lists the dependencies in your manifest. No login is needed, the file stays on your machine, and it handles up to 100 dependencies.
Quick check
Why does an always false condition matter?
The code it guards never runs. If that code was a check or cleanup step, the program silently skips it.
How do I catch these?
Static analysis and compiler warnings for constant conditions, plus branch coverage that shows never executed code.
