A10—Mishandling of Exceptional Conditions

>Control Description

Mishandling of Exceptional Conditions is a new category for 2025. This category contains 24 CWEs and focuses on improper error handling, logical errors, failing open, and other related scenarios stemming from abnormal conditions and systems may encounter. This category has some CWEs that were previously associated with poor code quality. That was too general for us; in our opinion, this more specific category provides better guidance. Notable CWEs included in this category: *CWE-209 Generation of Error Message Containing Sensitive Information, CWE-234 Failure to Handle Missing Parameter, CWE-274 Improper Handling of Insufficient Privileges, CWE-476 NULL Pointer Dereference,* and *CWE-636 Not Failing Securely ('Failing Open')*. Mishandling exceptional conditions in software happens when programs fail to prevent, detect, and respond to unusual and unpredictable situations, which leads to crashes, unexpected behavior, and sometimes vulnerabilities. This can involve one or more of the following 3 failings; the application doesn’t prevent an unusual situation from happening, it doesn’t identify the situation as it is happening, and/or it responds poorly or not at all to the situation afterwards. Exceptional conditions can be caused by missing, poor, or incomplete input validation, or late, high level error handling instead at the functions where they occur, or unexpected environmental states such as memory, privilege, or network issues, inconsistent exception handling, or exceptions that are not handled at all, allowing the system to fall into an unknown and unpredictable state. Any time an application is unsure of its next instruction, an exceptional condition has been mishandled. Hard-to-find errors and exceptions can threaten the security of the whole application for a long time. Many different security vulnerabilities can happen when we mishandle exceptional conditions, such as logic bugs, overflows, race conditions, fraudulent transactions, or issues with memory, state, resource, timing, authentication, and authorization. These types of vulnerabilities can negatively affect the confidentiality, availability, and/or integrity of a system or it’s data. Attackers manipulate an application's flawed error handling to strike this vulnerability.

>Prevention & Mitigation Strategies

1.Plan for exceptional conditions proactively — expect the worst and design for it.
2.Catch every possible system error directly at the place where it occurs and handle it meaningfully to solve problems and ensure recovery.
3.Error handling should include throwing an error to inform the user in an understandable way, logging the event, and issuing an alert when justified.
4.Have a global exception handler in place as a safety net in case there is ever something that was missed.
5.Implement monitoring and observability tooling that watches for repeated errors or attack patterns and issues appropriate responses.
6.Roll back every part of a transaction upon error and start again, also known as failing closed. Do not attempt partial recovery.
7.Add rate limiting, resource quotas, throttling, and other limits wherever possible to prevent exceptional conditions from occurring in the first place.
8.Consider outputting identical repeated errors above certain rates as statistics rather than individual messages.
9.Implement strict input validation with sanitization or escaping for potentially hazardous characters.
10.Establish centralized error handling, logging, monitoring, and alerting across the application.
11.Conduct threat modeling and secure design review activities, code reviews or static analysis, and stress, performance, and penetration testing.
12.Ensure your entire organization handles exceptional conditions in the same way — standardize the approach.

>Attack Scenarios

#1Resource exhaustion from unreleased file upload handles

Resource exhaustion via mishandling of exceptional conditions (Denial of Service) could be caused if the application catches exceptions when files are uploaded, but doesn’t properly release resources after. Each new exception leaves resources locked or otherwise unavailable, until all resources are used up.

#2Error message reconnaissance for SQL injection

Sensitive data exposure via improper handling or database errors that reveals the full system error to the user. The attacker continues to force errors in order to use the sensitive system information to create a better SQL injection attack. The sensitive data in the user error messages are reconnaissance.

#3Financial transaction state corruption via partial rollback

State corruption in financial transactions could be caused by an attacker interrupting a multi-step transaction via network disruptions. Imagine the transaction order was: debit user account, credit destination account, log transaction. If the system doesn’t properly roll back the entire transaction (fail closed) when there is an error part way through, the attacker could potentially drain the user’s account, or possibly a race condition that allows the attacker to send money to the destination multiple times.