CWE-391 is labeled planned for deprecation. MITRE's notes point readers to CWE-252, CWE-248 and CWE-1069. Even so, the core idea is worth knowing: ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed.
If you are mapping findings, prefer the replacement entries. If you are teaching developers, this entry is a clear statement of the habit to avoid.
How it happens
A call can fail, and the code never looks. In languages with checked exceptions the compiler pushes you toward handling; in languages with unnamed exceptions or plain return codes, nothing does.
FILE *f = fopen(path, "r");
fread(buf, 1, n, f); // f may be NULL, read count unchecked
MITRE notes a trade off in language design: unnamed exceptions make it easier to miss one, while named exceptions suffer from the up call version of the weak base class problem.
What an attacker gains
The consequence is integrity: an unexpected state, with altered execution logic. The system keeps running, but not on the path its authors intended.
How to find it
MITRE says automated static analysis can find some instances. Look for unchecked return values and empty handlers.
How to fix it
- Catch all relevant exceptions. MITRE calls this the recommended solution, and says to handle them so you can be sure of the system's state at any moment.
- Where the language allows, use one that requires catching all serious exceptions at compile time, and keep the API version current, since new exceptions can be added.
Quick check
Should I file new findings under CWE-391?
MITRE plans to deprecate it, so choose CWE-252, CWE-248 or CWE-1069 depending on the case.
