A function fails and tells nobody. The status stays "OK", the HTTP code stays 200, the caller moves on. CWE-392 is that weakness: the product encounters an error but does not provide a status code or return value to indicate that an error has occurred.
It affects any code with callers: libraries, APIs, web handlers and security checks. It is most dangerous when the swallowed error is part of a security decision.
How it happens
The cause is almost always a catch or error branch that handles the exception locally and then falls through to the success path.
boolean authenticate(String user, String pass) {
try {
return directory.bind(user, pass);
} catch (Exception e) {
log.error("bind failed", e);
}
return true; // error swallowed, caller sees success
}
The record gives four real examples:
- CVE-2024-52316: a web based product can throw an exception during authentication but does not report the failure in the HTTP status code, allowing authentication bypass.
- CVE-2004-0063: a function returns "OK" even if another function returns a different status code than expected, leading to acceptance of an invalid PIN.
- CVE-2002-1446: the error checking routine in a PKCS#11 library returns "OK" status even when an invalid signature is detected, allowing spoofed messages.
- A chain described in MITRE reference 1374: a JavaScript based cryptocurrency library can fall back to the insecure Math.random() function instead of reporting a failure, which reduces entropy.
The last one shows a quiet variant. No exception reaches the caller, but the code silently switches to a weaker path.
What an attacker gains
MITRE lists an integrity impact: errors that are not properly reported can place the system in an unexpected state that leads to unintended behavior. The examples above show how large that can be. An invalid PIN accepted, a forged signature accepted, or an authentication check that passes when it should not.
How to find it
The record lists no detection methods, so use review and testing:
- Read every catch block in authentication, signature and authorization code. Does each one end in a failure result?
- Search for functions that return a boolean true at the end after an exception handler.
- Write negative tests. Feed the function broken input, a dead dependency and an expired certificate, and assert that the result is a failure, not a success.
- Inject faults. Make the directory, database or crypto library error out, and watch what the caller reports.
- Flag silent fallbacks to weaker mechanisms, such as a different random source or a skipped verification step.
How to fix it
The record carries no mitigations, so here are plain steps that follow from the definition:
- Make failure the default. Initialize the result to denied and set it to allowed only on an explicit success.
- Propagate errors. Return an error code, raise an exception or set the proper HTTP status, and make sure callers check it.
- Never fall back silently from a strong mechanism to a weak one. If the secure path fails, fail.
- Return the real status code from web handlers. A 200 with an error message in the body is easy for clients and gateways to misread.
boolean authenticate(String user, String pass) {
try {
return directory.bind(user, pass);
} catch (Exception e) {
log.error("bind failed", e);
return false; // fail closed
}
}
Pair this with a code review rule: any catch block in a security path must either rethrow or return a denial.
Quick check
Why is a silent fallback to a weaker function an instance of this weakness?
The code hit an error and did not report it. The caller believes the strong mechanism worked, while the system actually used a weaker one.
What is the safest default for an authentication helper?
Return denied unless the check explicitly succeeds, so any unreported error ends in denial.
