CVE-2026-77582 in Tinyauth
Summary
by MITRE • 09/21/2026
Tinyauth is an authentication and authorization server. Prior to 5.1.0, Tinyauth exposes a remotely observable timing difference between authentication attempts for existing and nonexistent local usernames. internal/controller/user_controller.go loginHandler and internal/middleware/context_middleware.go basicAuth return quickly after internal/service/auth_service.go reports a missing user, while an existing user causes bcrypt password verification work. Repeated measurements can therefore disclose valid usernames and support targeted credential attacks. This issue is fixed in version 5.1.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/21/2026
The vulnerability identified in Tinyauth prior to version 5.1.0 represents a classic timing side-channel attack vector within an authentication system. As an authentication and authorization server, the integrity of user identity verification relies heavily on consistent processing times regardless of whether credentials are valid or invalid. In versions preceding the fix, the application logic exhibited a measurable discrepancy in response latency depending on the existence of the provided username. Specifically, when a request was made for a non-existent local username, the system returned quickly after determining that no user record existed. Conversely, requests targeting existing usernames triggered additional computational overhead due to bcrypt password verification processes before returning an authentication failure if the password was incorrect. This difference in execution time creates a distinguishable signal that can be exploited by remote attackers.
From a technical perspective, the flaw resides in the sequential evaluation of credentials within the internal controller and middleware layers. The login handler in user_controller.go and the basicAuth middleware in context_middleware.go are designed to perform authentication checks. However, they do not implement constant-time comparison or uniform processing delays for all code paths leading up to password verification. When auth_service.go reports a missing user, the function exits early without invoking bcrypt. For existing users, the system proceeds to hash and compare passwords using bcrypt, which is intentionally computationally expensive to resist brute-force attacks. This architectural decision, while standard for preventing credential stuffing via rapid iteration, inadvertently introduces a timing leak when combined with an early exit on invalid usernames rather than uniform dummy processing or consistent delays.
The operational impact of this vulnerability allows attackers to enumerate valid usernames through repeated network measurements. By sending multiple authentication requests and analyzing the response times, an adversary can statistically distinguish between existing and non-existing accounts. Once valid usernames are identified, these credentials become prime targets for targeted credential stuffing attacks, brute-force attempts, or social engineering efforts. This undermines the confidentiality of user identities and facilitates further exploitation phases where specific account compromise is attempted with higher efficiency than if all users were treated identically in terms of response time.
This vulnerability aligns with CWE-208, which describes Observable Timing Discrepancy, a category of flaws where sensitive information can be inferred from the amount of time taken to perform an operation. It also relates to CWE-359, Exposure of Private Information Through Timing Analysis. In terms of offensive security frameworks such as MITRE ATT&CK, this behavior supports techniques under T1087, Account Discovery, specifically Remote Account Discovery (T1087.004). The ability to enumerate accounts is often a precursor to lateral movement or privilege escalation within an organization's infrastructure.
To mitigate this vulnerability and similar timing side-channels in authentication systems, developers should ensure that all code paths return after approximately the same amount of time regardless of whether the username exists or not. This can be achieved by performing bcrypt verification even for non-existent users using a dummy password and hash, thereby ensuring consistent computational load. Alternatively, introducing artificial delays to shorter execution paths can help mask timing differences. Additionally, implementing rate limiting on authentication endpoints is crucial to prevent automated enumeration attacks from succeeding regardless of the underlying code structure. Organizations running Tinyauth versions prior to 5.1.0 should upgrade immediately to patch this logic flaw and restore uniform response behavior for all authentication attempts.