Sending a malformed request to a customer web application returns a page showing a full stack trace with the database server name, table names and the framework version. Which vulnerability does this reveal?

Unsafe exception handling occurs when an application does not catch and handle errors properly and instead returns raw error output to the client. Stack traces, database server names, table names and framework versions give attackers valuable reconnaissance, helping them craft injection attacks and identify known vulnerabilities for the exact version in use. The correct pattern is to catch exceptions, return a generic error message to the user and record the details in server-side logs that only administrators can read. A race condition depends on the timing of concurrent operations and would show inconsistent results, not a single malformed request producing a stack trace. Hardcoded secrets are credentials embedded in code; nothing in the error output described includes a password or key, and the weakness here is what the error handler reveals rather than what the code stores. A malicious update involves compromised code delivered through an update channel, which has no connection to how the application displays errors. Exam caveat: verbose errors are often classed as information disclosure, a vulnerability that amplifies other attacks rather than compromising the system by itself. Operational check: configure production error handling to return generic messages, confirm by sending malformed input again, and verify that the full details still reach the server logs.