[PLANNED FOR DEPRECATION. SEE MAINTENANCE NOTES AND CONSIDER CWE-252, CWE-248, OR CWE-1069.] Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed.

Primary

Implementation
REALIZATION: This weakness is caused during implementation of an architectural security tactic.

Medium

Integrity
Other
Varies by Context
Unexpected State
Alter Execution Logic

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.)
High

Requirements
The choice between a language which has named or unnamed exceptions needs to be done. While unnamed exceptions exacerbate the chance of not properly dealing with an exception, named exceptions suffer from the up call version of the weak base class problem.

Requirements
A language can be used which requires, at compile time, to catch all serious exceptions. However, one must make sure to use the most current version of the API as new exceptions could be added.

Implementation
Catch all relevant exceptions. This is the recommended solution. Ensure that all exceptions are handled in such a way that you can be sure of the state of your system at any given moment.

The following code excerpt ignores a rarely-thrown exception from doExchange().

try {doExchange();}catch (RareException e) {

// this can never happen

}

If a RareException were to ever be thrown, the program would continue to execute as though nothing unusual had occurred. The program records no evidence indicating the special situation, potentially frustrating any later attempt to explain the program's behavior.

Unchecked Return Value

Empty Catch Block

Uncaught exception

A7
Improper Error Handling
CWE More Specific

ERR00-C
Adopt and implement a consistent and comprehensive error-handling policy

ERR33-C
Detect and handle standard library errors
CWE More Abstract

ERR34-C
Detect errors when converting a string to a number
CWE More Abstract

FLP32-C
Prevent or detect domain and range errors in math functions
Imprecise

POS54-C
Detect and handle POSIX library errors
CWE More Abstract

EXP31-PL
Do not suppress or ignore exceptions
Imprecise

SFP4
Unchecked Status Condition

Prohibited
This entry is slated for deprecation; it has multiple widespread interpretations by CWE analysts. It combines information from three different taxonomies, but each taxonomy is talking about a slightly different issue.
Consider CWE-252, CWE-1069, CWE-248, or other entries under CWE-754: Improper Check for Unusual or Exceptional Conditions or CWE-755: Improper Handling of Exceptional Conditions.

This entry is slated for deprecation; it has multiple widespread interpretations by CWE analysts. It currently combines information from three different taxonomies, but each taxonomy is talking about a slightly different issue. CWE analysts might map to this entry based on any of these issues. 7PK has "Empty Catch Block" which has an association with empty exception block (CWE-1069); in this case, the exception has performed the check, but does not handle. In PLOVER there is "Unchecked Return Value" which is CWE-252, but unlike "Empty Catch Block" there isn't even a check of the issue - and "Unchecked Error Condition" implies lack of a check. For CLASP, "Uncaught Exception" (CWE-248) is associated with incorrect error propagation - uncovered in CWE 3.2 and earlier, at least. There are other issues related to error handling and checks.

When a programmer ignores an exception, they implicitly state that they are operating under one of two assumptions:

This method call can never fail.
It doesn't matter if this call fails.

PLOVER
2006-07-19
Draft 3
2006-07-19

Eric Dalci
Cigital
2008-07-01
updated Time_of_Introduction

KDM Analytics
2008-08-01
added/updated white box definitions

Veracode
2008-08-15
Suggested OWASP Top Ten 2004 mapping

CWE Content Team
MITRE
2008-09-08
updated Maintenance_Notes, Relationships, Other_Notes, Taxonomy_Mappings

CWE Content Team
MITRE
2008-11-24
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2009-05-27
updated Demonstrative_Examples

KDM Analytics
2009-07-17
Improved the White_Box_Definition

CWE Content Team
MITRE
2009-07-27
updated White_Box_Definitions

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences

CWE Content Team
MITRE
2011-06-27
updated Common_Consequences

CWE Content Team
MITRE
2011-09-13
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2012-05-11
updated Relationships

CWE Content Team
MITRE
2012-10-30
updated Potential_Mitigations

CWE Content Team
MITRE
2014-06-23
updated Other_Notes

CWE Content Team
MITRE
2014-07-30
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2017-11-08
updated Applicable_Platforms, Modes_of_Introduction, Relationships, Taxonomy_Mappings, White_Box_Definitions

CWE Content Team
MITRE
2019-01-03
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2019-06-20
updated Description, Maintenance_Notes

CWE Content Team
MITRE
2020-02-24
updated References

CWE Content Team
MITRE
2020-08-20
updated Relationships

CWE Content Team
MITRE
2020-12-10
updated Relationships

CWE Content Team
MITRE
2021-03-15
updated Description, Relationships

CWE Content Team
MITRE
2021-07-20
updated Relationships

CWE Content Team
MITRE
2023-04-27
updated Detection_Factors, Relationships, Time_of_Introduction

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2024-02-29
4.14
2024-02-29
updated Mapping_Notes

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Relationships, Weakness_Ordinalities