CVE-2026-77561 in Tinyauth
Summary
by MITRE • 09/21/2026
Tinyauth is an authentication and authorization server. Prior to 5.1.0, an unauthenticated remote attacker can send POST /api/user/login requests with 257 distinct nonexistent usernames to fill MaxLoginAttemptRecords and activate a global login lockdown. internal/controller/user_controller.go loginHandler passes each attacker-controlled identifier to internal/service/auth_service.go RecordLoginAttempt, which invokes lockdownMode after the map reaches its cap. IsAccountLocked checks that global state before validating unrelated accounts, causing valid users to receive HTTP 429 until auth.loginTimeout expires, approximately 300 seconds by default. The attack can be repeated, but existing authenticated sessions are not invalidated. This issue is fixed in version 5.1.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/21/2026
The vulnerability identified in Tinyauth prior to version 5.1.0 represents a critical availability risk stemming from an improper implementation of rate limiting and account lockout mechanisms within the authentication subsystem. As an authentication and authorization server, Tinyauth is responsible for managing user access credentials and enforcing security policies during login attempts. The flaw resides specifically in how the system handles failed login attempts across different usernames, allowing an unauthenticated remote attacker to trigger a global denial-of-service condition by exploiting the interaction between individual account tracking and global state management.
The technical root cause lies in the logic flow of the login handler located at internal/controller/user_controller.go. When a POST request is sent to /api/user/login, the system invokes RecordLoginAttempt from internal/service/auth_service.go to track failed credentials. This function maintains a map or data structure that records login failures for specific usernames. However, this tracking mechanism has a fixed capacity defined by MaxLoginAttemptRecords. Once an attacker sends requests with 257 distinct nonexistent usernames, each triggering a failure record, the underlying storage reaches its maximum cap. Upon reaching this limit, the system erroneously activates a global lockdown mode rather than simply discarding older records or handling overflow gracefully. This design flaw causes the IsAccountLocked function to check for this global state before validating credentials for any specific account, including legitimate users with valid usernames and passwords.
The operational impact of this vulnerability is severe, resulting in a complete denial of service for all authenticated and unauthenticated users attempting to log in. Once the lockdown mode is activated by the attacker's flood of requests using unique fake identities, every subsequent login attempt from any user receives an HTTP 429 Too Many Requests response. This effectively locks out legitimate administrators and end-users, preventing them from accessing their accounts or performing critical operations within the system. The lockout persists for a duration defined by auth.loginTimeout, which defaults to approximately 300 seconds. During this window, the authentication service is entirely unresponsive to new login attempts, disrupting business continuity and potentially causing significant downtime depending on the frequency of access required by users.
It is important to note that while this attack successfully blocks new logins, it does not invalidate existing authenticated sessions or tokens. Therefore, active connections remain functional until they expire naturally, but no new authentication can occur during the lockdown period. Furthermore, because the mechanism relies on reaching a specific count of distinct failed attempts from unique identifiers, an attacker can repeat this process indefinitely to maintain continuous denial-of-service conditions against the service. This persistence makes it particularly dangerous in environments where availability is paramount and automated attacks are common.
From a classification perspective, this vulnerability aligns with CWE-780: Use of RSA Algorithm for Key Wrapping if considered under broader cryptographic misuse contexts, but more accurately maps to CWE-693: Protection Mechanism Failure due to the failure of the security control (rate limiting/lockout) to function as intended. In terms of attack tactics, this behavior is consistent with MITRE ATT&CK technique T1499: Endpoint Denial of Service, specifically under subcategories involving resource exhaustion or service disruption through application layer attacks. The attacker leverages legitimate authentication endpoints to exhaust system resources and trigger defensive mechanisms that inadvertently harm availability rather than security.
Mitigation for this vulnerability requires upgrading Tinyauth to version 5.1.0 or later, where the logic has been corrected to prevent global lockdowns from being triggered by individual account lockouts reaching capacity limits. For systems unable to upgrade immediately, administrators should implement network-level rate limiting on the /api/user/login endpoint using firewalls or reverse proxies to restrict the number of requests per source IP address over a given time window. Additionally, configuring distinct timeouts and maximum attempt thresholds for both global and per-user states can help isolate failures so that one user's excessive attempts do not impact others. Monitoring logs for spikes in 401 Unauthorized responses from diverse usernames originating from single or few IPs can also aid in early detection of such abuse patterns before the lockout threshold is reached.