Always-Incorrect Control Flow Implementation

Draft Class
Structure: Simple
Description

This weakness occurs when a section of code is structured in a way that always executes incorrectly, regardless of input or conditions. The control flow logic is fundamentally flawed and does not match the intended algorithm.

Extended Description

Unlike many security flaws that are triggered by unexpected or malicious data, this issue represents a permanent logic error in the code. The problematic path is always wrong, meaning the software will behave incorrectly every time that specific code segment runs. This is often the result of simple syntactic mistakes, like omitting curly braces in C-style languages, which changes which statements are included in a conditional block. For developers, this means the bug is not situational; it's a constant defect in the program's logic. Identifying these flaws requires carefully reviewing the intended algorithm against the actual code structure, as standard testing with varied inputs might not reveal the root cause—the logic itself is broken from the start.

Common Consequences 1
Scope: Other

Impact: OtherAlter Execution Logic

Demonstrative Examples 4

ID : DX-180

This code queries a server and displays its status when a request comes from an authorized IP address.

Code Example:

Bad
PHP
php

...*

This code redirects unauthorized users, but continues to execute code after calling http_redirect(). This means even unauthorized users may be able to access the contents of the page or perform a DoS attack on the server being queried. Also, note that this code is vulnerable to an IP address spoofing attack (Improper Removal of Sensitive Information Before Storage or Transfer).

ID : DX-181

In this example, the programmer has indented the statements to call Do_X() and Do_Y(), as if the intention is that these functions are only called when the condition is true. However, because there are no braces to signify the block, Do_Y() will always be executed, even if the condition is false.

Code Example:

Bad
C
c
This might not be what the programmer intended. When the condition is critical for security, such as in making a security decision or detecting a critical error, this may produce a vulnerability.

ID : DX-182

In both of these examples, a message is printed based on the month passed into the function:

Code Example:

Bad
Java
java

Code Example:

Bad
C
c
Both examples do not use a break statement after each case, which leads to unintended fall-through behavior. For example, calling "printMessage(10)" will result in the text "OctoberNovemberDecember is a great month" being printed.

ID : DX-183

In the excerpt below, an AssertionError (an unchecked exception) is thrown if the user hasn't entered an email address in an HTML form.

Code Example:

Bad
Java
java
Observed Examples 1
CVE-2021-3011virtual interrupt controller in a virtualization product allows crash of host by writing a certain invalid value to a register, which triggers a fatal error instead of returning an error code
Modes of Introduction
Implementation
Notes
MaintenanceThis node could possibly be split into lower-level nodes. "Early Return" is for returning control to the caller too soon (e.g., Return Inside Finally Block). "Excess Return" is when control is returned too far up the call stack (Uncaught Exception in Servlet , Use of NullPointerException Catch to Detect NULL Pointer Dereference). "Improper control limitation" occurs when the product maintains control at a lower level of execution, when control should be returned "further" up the call stack (Non-exit on Failed Initialization). "Incorrect syntax" covers code that's "just plain wrong" such as Omitted Break Statement in Switch and Incorrect Block Delimitation.