CVE-2026-100677
Summary
by MITRE • 09/26/2026
stoatchat before 0.15.5 contains an account enumeration vulnerability in the login endpoint that exposes source file locations in error responses. Unauthenticated attackers can distinguish between registered and unregistered email addresses by comparing error location fields returned from POST /api/auth/session/login requests.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/26/2026
The identified security flaw within stoatchat versions prior to 0.15.5 represents a classic account enumeration vulnerability rooted in improper handling of authentication errors. This specific weakness allows an unauthenticated attacker to systematically determine whether a given email address is associated with a registered user account on the platform. The root cause lies in the application's error response mechanism, which inadvertently leaks sensitive internal implementation details by exposing source file locations within HTTP responses generated during failed login attempts. When an attacker submits a POST request to the /api/auth/session/login endpoint with varying email addresses, the server processes these requests and returns distinct error payloads depending on whether the provided credentials correspond to an existing account or not.
From a technical perspective, this vulnerability exploits the principle of information leakage through inconsistent application behavior. In many web applications, developers may implement different error messages for invalid usernames versus invalid passwords to aid in debugging during development phases but fail to sanitize these responses before deployment. In this case, the presence of source file paths or stack trace details within the error response serves as a clear indicator that distinguishes between registered and unregistered email addresses. An attacker can automate this process by sending multiple login requests with different email identifiers while monitoring the structure and content of the returned HTTP errors. If an error message includes specific internal path information, it may indicate one state of account existence, whereas its absence or variation might signal another, thereby allowing the attacker to build a list of valid user accounts without needing any prior authentication credentials.
The operational impact of this vulnerability is significant as it facilitates further malicious activities such as targeted phishing attacks, credential stuffing campaigns, and social engineering efforts. By obtaining a verified list of email addresses associated with active users, attackers can tailor their spear-phishing attempts to appear more legitimate or focus brute-force password attacks on accounts that are confirmed to exist. This reduces the noise in attack traffic and increases the success rate of subsequent exploitation attempts against user credentials. Furthermore, the exposure of source file locations adds an additional layer of risk by potentially revealing details about the underlying technology stack, framework versions, or directory structures used by the application server. Such information can be leveraged to identify other potential vulnerabilities specific to those technologies, effectively widening the attack surface beyond just account enumeration.
This vulnerability aligns with CWE-203, which describes observable discrepancy in system behavior that reveals sensitive information, and is closely related to CWE-284 regarding improper access control during authentication processes. In terms of offensive security frameworks, this technique corresponds to ATT&CK tactic T1596, specifically the sub-technique of Gather Victim Host Information through active scanning or enumeration methods like Account Enumeration (T1078). The ability to distinguish valid accounts is a critical precursor step in many advanced persistent threat campaigns and automated attack tools.
To mitigate this vulnerability, developers must ensure that all error responses returned by authentication endpoints are generic and do not disclose internal implementation details such as file paths, stack traces, or database query errors. It is essential to implement consistent response structures for both valid and invalid login attempts so that an attacker cannot derive any information about account existence from the HTTP response body or status codes alone. Additionally, implementing rate limiting on the login endpoint can help mitigate automated enumeration attacks by restricting the number of requests a single IP address can make within a given time window. Regular security code reviews should also be conducted to identify and remove debug logging statements that might inadvertently expose sensitive data in production environments.