Category: Error Conditions, Return Values, Status Codes
Incomplete
Summary
This category includes weaknesses that occur if a function does not generate the correct return/status code, or if the application does not handle all possible return/status codes that could be generated by a function. This type of problem is most often found in conditions that are rarely encountered during the normal operation of the product. Presumably, most bugs related to common conditions are found and eliminated during development and testing. In some cases, the attacker can directly control or influence the environment to trigger the rare conditions.
Membership
| ID | Name | Description |
|---|---|---|
| CWE-209 | Generation of Error Message Containing Sensitive Information | This vulnerability occurs when an application reveals sensitive details about its internal systems, user data, or environment within error messages shown to users. |
| 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-252 | Unchecked Return Value | This vulnerability occurs when a program fails to verify the result of a function or method call, allowing it to continue execution without detecting errors or unexpected conditions. |
| CWE-253 | Incorrect Check of Function Return Value | This vulnerability occurs when a program misinterprets or improperly validates the return value from a function, causing it to miss critical error states or unexpected conditions. |
| CWE-390 | Detection of Error Condition Without Action | This weakness occurs when software successfully identifies an error condition but then fails to take any meaningful action to address it. The error is detected but ignored, leaving the system in an inconsistent or vulnerable state. |
| CWE-391 | Unchecked Error Condition | This vulnerability occurs when a program fails to properly check or handle error conditions, such as exceptions or return codes. By ignoring these failures, the software can enter an unexpected state that attackers might exploit, often without any logging or user notification. |
| CWE-392 | Missing Report of Error Condition | This vulnerability occurs when a system fails to properly signal that an error has happened. Instead of returning a clear error code, status, or exception, the software continues as if nothing went wrong, leaving other components unaware of the failure. |
| CWE-393 | Return of Wrong Status Code | This vulnerability occurs when a function returns an inaccurate status code or value that misrepresents the actual outcome of an operation. This false signal can cause the application to behave in unexpected and potentially insecure ways. |
| CWE-394 | Unexpected Status Code or Return Value | This vulnerability occurs when software fails to properly validate the full range of possible return values from a function or system call. While a returned value might be technically valid for that operation, the application doesn't anticipate or handle it correctly, leading to unexpected behavior. |
| 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-544 | Missing Standardized Error Handling Mechanism | This weakness occurs when software lacks a unified, consistent approach to managing errors across its codebase, leading to unpredictable security gaps and unreliable behavior. |
| 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-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-756 | Missing Custom Error Page | This vulnerability occurs when an application fails to display its own user-friendly error pages, instead falling back to default system messages that can leak sensitive technical details. |
| CWE-699 | Software Development | This view organizes weaknesses around concepts that are frequently used or encountered in software development. This includes all aspects of the software development lifecycle including both architecture and implementation. Accordingly, this view can align closely with the perspectives of architects, developers, educators, and assessment vendors. It provides a variety of categories that are intended to simplify navigation, browsing, and mapping. |
Vulnerability Mapping Notes
Usage: Prohibited
Reasons: Category
Rationale:
This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.
Comment:
See member weaknesses of this category.