Weaknesses in this category are related to insufficient control flow management.
| ID | Name | Description |
|---|---|---|
| CWE-1190 | DMA Device Enabled Too Early in Boot Phase | This vulnerability occurs when a device with Direct Memory Access (DMA) capability is activated before the system's security settings are fully locked in during the boot process. This oversight can let an attacker bypass normal protections to read sensitive data from memory or escalate their privileges on the system. |
| CWE-1193 | Power-On of Untrusted Execution Core Before Enabling Fabric Access Control | This vulnerability occurs when a system powers up hardware components containing untrusted firmware before establishing critical security controls for the system's internal communication pathways and memory. |
| CWE-1265 | Unintended Reentrant Invocation of Non-reentrant Code Via Nested Calls | This vulnerability occurs when a non-reentrant function is called, and during its execution, another call is triggered that unexpectedly re-enters the same non-reentrant code path, corrupting its internal state. |
| CWE-1280 | Access Control Check Implemented After Asset is Accessed | This vulnerability occurs when a hardware-based security check runs after the protected resource has already been accessed, creating a dangerous timing window. |
| CWE-1281 | Sequence of Processor Instructions Leads to Unexpected Behavior | Certain sequences of valid and invalid processor instructions can cause the CPU to lock up or behave unpredictably, often requiring a hard reset to recover. |
| CWE-1322 | Use of Blocking Code in Single-threaded, Non-blocking Context | This vulnerability occurs when an application designed to be single-threaded and non-blocking, for performance and scalability, inadvertently executes code that can block the entire process. If an attacker can trigger this blocking code, it can cause the application to freeze, leading to a denial of service. |
| CWE-179 | Incorrect Behavior Order: Early Validation | This vulnerability occurs when an application validates user input before applying security filters or data normalization. Attackers can exploit this order of operations by submitting specially crafted input that passes the initial validation but becomes malicious after the application's filters or canonicalization processes modify it. |
| CWE-180 | Incorrect Behavior Order: Validate Before Canonicalize | This vulnerability occurs when a system checks user input for malicious content before standardizing its format, allowing specially crafted data to bypass security checks. |
| CWE-181 | Incorrect Behavior Order: Validate Before Filter | This vulnerability occurs when a system checks user input for validity before cleaning or filtering it. This flawed sequence allows malicious data to pass validation, only to be altered by later filters into a dangerous form. |
| CWE-248 | Uncaught Exception | This vulnerability occurs when a function throws an error or exception, but the calling code does not have a proper handler to catch and manage it. |
| CWE-382 | J2EE Bad Practices: Use of System.exit() | This vulnerability occurs when a J2EE application directly calls System.exit(), which forcibly terminates the entire application server process, not just the application itself. |
| CWE-395 | Use of NullPointerException Catch to Detect NULL Pointer Dereference | Using a try-catch block for NullPointerException as a substitute for proper null checks is an anti-pattern. This approach masks the root cause of null pointer dereferences instead of preventing them, leading to unstable and difficult-to-debug code. |
| CWE-396 | Declaration of Catch for Generic Exception | This weakness occurs when code catches a generic exception type like 'Exception' or 'Throwable', which can hide specific errors and create insecure error handling logic. |
| CWE-397 | Declaration of Throws for Generic Exception | This vulnerability occurs when a method is declared to throw an overly broad exception type, such as a generic 'Exception' or 'Throwable'. This practice masks the specific error conditions that can occur, making it difficult for calling code to handle failures appropriately. |
| CWE-408 | Incorrect Behavior Order: Early Amplification | This vulnerability occurs when a system allows a user to trigger a resource-intensive operation before verifying their identity or checking their permissions. |
| CWE-430 | Deployment of Wrong Handler | This vulnerability occurs when a system incorrectly assigns or routes an object to the wrong processing component. |
| CWE-431 | Missing Handler | This vulnerability occurs when a software component lacks the necessary code to properly handle an error or unexpected event. |
| CWE-455 | Non-exit on Failed Initialization | This vulnerability occurs when software continues to run as normal after encountering a critical security failure during its startup process. Instead of halting or entering a safe mode, the application proceeds with weakened or missing security controls, leaving it exposed. |
| CWE-480 | Use of Incorrect Operator | This vulnerability occurs when a developer mistakenly uses the wrong operator in their code, leading to unintended and potentially insecure logic. |
| CWE-481 | Assigning instead of Comparing | This flaw occurs when a developer accidentally uses the assignment operator (=) instead of the comparison operator (== or ===). The code assigns a value when it was meant to check for equality, which fundamentally changes the program's logic. |
| CWE-482 | Comparing instead of Assigning | This vulnerability occurs when a developer accidentally uses a comparison operator (like '==') where an assignment operator (like '=') was intended, creating a logic error instead of setting a value. |
| CWE-483 | Incorrect Block Delimitation | This vulnerability occurs when a developer fails to use explicit braces or delimiters to group multiple statements within a block, leading to unexpected program logic. |
| CWE-584 | Return Inside Finally Block | This vulnerability occurs when a function places a return statement inside a finally block. This dangerous pattern silently discards any unhandled exceptions thrown earlier in the try block, making errors invisible and undermining application stability. |
| CWE-600 | Uncaught Exception in Servlet | This vulnerability occurs when a Java Servlet fails to properly catch and handle exceptions, potentially exposing sensitive system information in error messages. |
| CWE-617 | Reachable Assertion | A reachable assertion occurs when an attacker can trigger an assert() statement or similar debugging check, causing the application to crash or behave in a more disruptive way than intended. This turns a helpful development tool into a denial-of-service vulnerability. |
| CWE-670 | Always-Incorrect Control Flow Implementation | 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. |
| CWE-674 | Uncontrolled Recursion | This vulnerability occurs when an application fails to limit how deeply a function can call itself. Without proper controls, this uncontrolled recursion can exhaust system resources like memory or stack space, leading to crashes or denial-of-service. |
| CWE-691 | Insufficient Control Flow Management | This vulnerability occurs when a program's execution flow isn't properly managed, allowing attackers to bypass critical checks, trigger unexpected code paths, or disrupt normal operation. |
| CWE-696 | Incorrect Behavior Order | This weakness occurs when a system executes multiple dependent actions in the wrong sequence, leading to unexpected and potentially vulnerable states. |
| CWE-698 | Execution After Redirect (EAR) | Execution After Redirect (EAR) occurs when a web application sends a redirect response to a user's browser but continues to run server-side code, potentially performing unintended actions. |
| CWE-705 | Incorrect Control Flow Scoping | This vulnerability occurs when a program fails to return execution to the correct point in the code after finishing a specific operation or handling an error. Instead of resuming normal flow, it may jump to an unintended location, leading to unpredictable behavior or security issues. |
| CWE-768 | Incorrect Short Circuit Evaluation | This vulnerability occurs when a program's conditional statement uses short-circuit evaluation (where later parts of an AND/OR check are skipped if the outcome is already determined), and the skipped portions contain code that changes the program's state. Because these side effects—like updating a variable, checking a permission, or logging an event—are never executed, the application can enter an unexpected and potentially insecure state. |
| CWE-783 | Operator Precedence Logic Error | This vulnerability occurs when a developer writes a conditional expression where the intended logic is broken due to misunderstanding or misapplying the rules of operator precedence. |
| CWE-799 | Improper Control of Interaction Frequency | This vulnerability occurs when an application fails to properly restrict how often or how many times a user or automated system can interact with it. |
| CWE-834 | Excessive Iteration | This vulnerability occurs when a program runs a loop too many times because it lacks proper limits on its iterations. |
| CWE-835 | Loop with Unreachable Exit Condition ('Infinite Loop') | An infinite loop occurs when a program's iteration logic contains an exit condition that can never be satisfied, causing the loop to run indefinitely and consume system resources. |
| CWE-837 | Improper Enforcement of a Single, Unique Action | This vulnerability occurs when a system fails to properly prevent users from repeating an action that should only be performed once, such as submitting a vote, finalizing a purchase, or requesting a refund. |
| CWE-841 | Improper Enforcement of Behavioral Workflow | This weakness occurs when an application requires a user to follow a specific sequence of actions, but fails to enforce that order. Attackers can exploit this by skipping steps, performing actions out of sequence, or interrupting the flow, which can corrupt the business logic or put the system into an invalid state. |
| CWE-1400 | Comprehensive Categorization for Software Assurance Trends |