CWE-431 is simple to state: a handler is not available or implemented. MITRE adds that when an exception is thrown and not caught, the process gives up the opportunity to decide whether a failure or event warrants a change in execution.
How it happens
A cast, parse or network call can fail. The code assumes it will not, and nothing catches the error. The default behavior takes over, often a crash.
MITRE's example is an OPC UA SDK that lacked a handler for a failed cast, allowing a crash (CVE-2022-25302).
# Vulnerable: bad input raises and kills the worker
value = int(request.args["count"])
# Fixed: handle the failure and reply cleanly
try:
value = int(request.args["count"])
except (KeyError, ValueError):
return error_response(400, "invalid count")
What an attacker gains
The record says the impact varies by context. A crash caused by one malformed input is a denial of service for everyone sharing that process.
How to find it
The record lists no detection methods. Fuzz your parsers and message handlers, and review calls that can throw for a matching catch.
How to fix it
- Handle expected errors where they occur.
- Add a top level handler so unexpected errors are logged and contained.
- Isolate untrusted input handling so one failure does not stop the service.
Where gaps appear
Missing handlers cluster at boundaries: parsing network input, deserializing data, casting between types, and callbacks that the framework calls on your behalf. Libraries that speak industrial or binary protocols are especially exposed because every malformed message is a new way to hit an unplanned branch. Fuzzing a protocol parser for an hour often finds more unhandled cases than a week of code review.
Quick check
Should I catch every exception and carry on?
No. Handle what you can act on, and fail safely on the rest, with logging.
