To protect client privacy, the endpoint name /app/users/ used throughout this security write-up has been generalized. It serves as an illustrative example to detail the vulnerability without exposing the specific, real-world endpoint.
It’s the kind of subtle flaw that keeps security professionals up at night. A routine timeout error on a customer's /app/users/ endpoint, something most tools would flag as a simple performance issue, was actually hiding a critical vulnerability with the potential to expose an entire user database. The discovery, led by Hadrian’s Hacking Manager Melvin Lammerts, began when our team noticed something odd: while the endpoint consistently timed out, simply extending the client-side timeout threshold caused the server to return a complete list of every user. This incident serves as a powerful reminder that the most significant risks often lie concealed behind seemingly harmless application behaviors, far beyond the reach of standard automated scans.
Why Automated Scanners Miss Critical Vulnerabilities
Modern vulnerability scanners are built for speed. They sift through thousands of endpoints to find well-known patterns, and to do this effectively, they must filter out what they consider "noise." Non-200 HTTP status codes, like timeouts (504) or server errors (500), are often dismissed as temporary network issues or simple misconfigurations rather than potential security flaws. To a scanner, a timeout on an endpoint like /app/users/ usually just means a performance bottleneck. As a result, deep analysis is almost always reserved for 200 OK responses, which confirm an endpoint is working as expected. An endpoint that consistently fails can thus remain in a perpetual blind spot, logged but never escalated, hiding its secrets from automated audits.
Manual Vulnerability Investigation
This is where the expertise of Hadrian's security team made all the difference. While reviewing routine scan logs, Melvin Lammerts noticed the recurring timeouts on the /app/users/ endpoint. An automated system would have moved on, but his experience suggested it might be more than a simple performance glitch. He theorized that the server wasn't actually failing—it was just incredibly slow. The application's backend was likely trying to run a massive, unbounded database query, like a findAll() on the entire user table, and assemble the full dataset before sending a response. Standard HTTP clients, with their default 30-second timeouts, were simply giving up long before the server could finish its work.
To test this theory, the team crafted a custom script. Its function was simple but powerful: make a GET request to the /app/users/ endpoint but wait for 600 seconds, far longer than the usual limit. This extended window was designed to give the server-side process—which had likely continued running in the background despite previous client disconnects—enough time to finish its heavy lifting.
Vulnerability Discovery and Impact
The result was immediate and alarming. After about 120 seconds of silence, the server responded not with an error, but with a 200 OK. The body of the response contained a massive JSON array exposing every single user in the customer's database, including sensitive information like email addresses, hashed passwords, and internal role assignments. A full-scale data exposure was confirmed. The vulnerability had been allowed to hide in plain sight because client-side tools and security scanners interpreted the timeout errors as operational noise, not security signals. The issue was cleverly disguised as a performance bug, likely deemed a low-priority ticket rather than the high-severity risk it truly was.
Mitigation Strategies and Best Practices
To prevent such data leaks, it's vital to treat recurring timeout errors as potential security signals, not just performance issues. When an error occurs, your application should return a generic, sanitized message to the client but log the full, detailed error context on the server for forensic analysis. Implement robust monitoring and alerting for spikes in non-200 status codes, especially timeouts, on sensitive endpoints.
Pagination is a non-negotiable security control for any API that returns lists of data. By breaking up large datasets into smaller, manageable chunks, you prevent the very possibility of an unbounded query that could overwhelm the server or expose massive amounts of information at once. It is one of the most effective defenses against mass data exposure.
Finally, a secure error path is just as critical as the success path. Your error handling routines must do more than just send a status code. They should gracefully terminate the underlying process and release all associated resources. If your server doesn't clean up properly after a client disconnects, you may be leaving a door wide open for attackers by allowing "orphaned" queries to continue running in the background.
Conclusion
This investigation reveals how a routine performance issue can mask a catastrophic data exposure vulnerability. The incident was not caused by a single flaw but by a chain reaction of common design weaknesses: unbounded queries, improper error handling, and the failure to recognize timeouts as security indicators. This vulnerability remained invisible to standard scanners, highlighting the absolute necessity of a security strategy that combines powerful automation with curious, hypothesis-driven human investigation. The key lesson is clear: your most dangerous threats may not announce themselves loudly but can hide within the "noise" your tools are trained to ignore.
