Mishandling of exceptional conditions is new in 2025. It replaces server-side request forgery in the number ten slot, which, as we discussed in module one, got consolidated into broken access control. This new category fills a gap: there are real, well-known classes of bugs that previously had no clean home in the Top 10. Now they do.

Twenty four distinct CWEs fall under this category. At its core, it's about what happens when your program encounters something unexpected. A race condition. A timeout from an external service. An error it didn't anticipate. A parameter missing from a request. An unusual combination of state. The question the category asks is: when that happens, does your application fail safely, or does it fail in a way an attacker can exploit?

Let me walk through what mishandling exceptional conditions actually looks like.

First, resource exhaustion as a denial of service. An application has an endpoint that uploads files. The endpoint catches exceptions when something goes wrong, but it doesn't release the resources it allocated before the exception. Each failed upload leaves a file handle or a database connection or a memory buffer locked. An attacker triggers the failure path repeatedly. Eventually every resource is exhausted and the application stops responding. A denial of service attack that exploits exception handling itself.

Second, sensitive data exposure through error messages. An application reveals full database error messages to users when queries fail. An attacker induces errors to learn the database schema, the query structure, and the underlying technology stack. Now they can craft a targeted SQL injection attack that bypasses the filters they can now see.

Third, state corruption in financial transactions. A money transfer has three steps: debit the source account, credit the destination account, log the transaction. The network connection drops after step one but before step two. A naive implementation might retry, or leave the source account debited without the destination credit. An attacker can deliberately induce these interruptions at scale, draining an account or causing race conditions that allow the same amount to land in the destination multiple times.

And fourth, TOCTOU bugs. Time of check to time of use. The application checks permissions at one moment, then performs an action a moment later, but between those two moments, state has changed. An attacker exploits the window. File-system operations are a classic case, where a symbolic link gets swapped in between the permission check and the actual file operation.

Notice the pattern. In every one of these, the application is doing something reasonable on the happy path. The bug lives in what happens when things don't go smoothly.

So how do you defend against this category?

First, fail closed, not open. When the system encounters an unexpected state, the default behavior should be to deny, reject, or abort, not to allow. A permission check that fails due to a database timeout should treat the timeout as a denial, not as a success.

Second, handle every possible error directly where it occurs. Not only at a global level. Every network call, every file operation, every database query should have explicit consideration of the failure path. Wrapping the whole application in a single try-catch at the top isn't handling errors. It's burying them.

Third, when a multi-step operation is interrupted, roll back cleanly. Don't attempt partial recovery. Don't try to retry from the middle. Restart the whole transaction, and ensure the rollback itself is tested and reliable.

Fourth, add rate limiting, resource quotas, and throttling at every boundary. Nothing in your system should be unlimited. Unbounded loops, unbounded file uploads, unbounded retries all create exception-condition vulnerabilities. Bound everything.

Fifth, don't leak sensitive information in error messages. Users get a generic "something went wrong." Your internal logs get the full details. Never the reverse.

And sixth, centralize your exception handling so the entire application responds to errors consistently. The same error in ten different places should not produce ten different behaviors. One pattern, one place.

Mishandling exceptional conditions is new to the Top 10, but the bugs aren't. What's new is that error handling has been promoted from "code hygiene" to a named security category. That's deserved. Treat it accordingly.

Quiz & Certification

Training content is freely available. Sign in and get a training credit to take quizzes, track progress, and generate compliance reports.