CWE-537, Java Runtime Error Message Containing Sensitive Information, is the plain Java version of a familiar mistake. MITRE says that in many cases an attacker can use the conditions that cause unhandled exception errors to gain unauthorized access to the system.
How it happens
Java code throws runtime exceptions when something unexpected arrives: a null value, a bad number, a missing file. If nothing catches the exception, it travels up to the container or framework, which may render it for the user. The message can carry details about the code and the environment.
What an attacker gains
MITRE lists reading application data as the confidentiality impact. The practical gain is knowledge. Each unhandled error teaches the attacker something about how the application is built, which makes the next probe better aimed.
How to find it
- Feed bad input to every endpoint: nulls, empty strings, non-numeric values where numbers are expected.
- Read the response bodies, not just the status codes.
- Search for broad places where exceptions are thrown but never caught at a boundary.
How to fix it
MITRE's mitigation for this entry is one sentence: do not expose sensitive error information to the user, applied during implementation. In steps:
- Add a single handler at the application boundary that catches exceptions.
- Return a generic message with a status code.
- Write the real exception to a server log that users cannot read.
try {
process(request);
} catch (RuntimeException e) {
logger.error("Request failed", e);
response.sendError(500, "Something went wrong");
}
Quick check
Where should the full exception go?
Into a server-side log that only your team can read, never into the response.
