Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-09-21T17:18:52.943Z",
  "pubdate": "2026-09-21T17:18:52.943Z",
  "executiveSummary": "Tinyauth versions prior to 5.1.0 are susceptible to a Denial-of-Service (DoS) vulnerability originating from an improper handling of login attempt tracking. An unauthenticated remote attacker can exploit the application's login mechanism to trigger a global lockdown state, effectively preventing all users from authenticating.\nThe vulnerability manifests because the server-side logic binds the login attempt tracking mechanism to a global state that is shared across all accounts. By sending a crafted series of POST requests with non-existent usernames, an attacker can exhaust the configured capacity of the login attempt records map (MaxLoginAttemptRecords).\nOnce this threshold is exceeded, the system activates a global lockdown mode, causing subsequent authentication attempts from any user—including legitimate ones—to be rejected with HTTP 429 status codes. This state persists until the expiration of the auth.loginTimeout period. The risk is significant as it allows an unauthenticated actor to disrupt service availability for the entire user base without requiring valid credentials or high-level privileges. The vulnerability is effectively remediated in version 5.1.0.",
  "technicalDetails": "The vulnerability resides in the interaction between internal/controller/user_controller.go and internal/service/auth_service.go within Tinyauth. The loginHandler function in the controller accepts user-supplied identifiers via POST /api/user/login requests. These identifiers are subsequently passed to the RecordLoginAttempt function located in the auth_service component.\nThe root cause of this vulnerability is the implementation of a global state for account lockdown that does not sufficiently differentiate between individual account security and global system availability. When RecordLoginAttempt processes an authentication request, it updates a internal mapping structure that tracks failed login attempts. This structure has a hard-coded or configured limit defined as MaxLoginAttemptRecords. When the number of unique identifiers processed exceeds this capacity, the service invokes the lockdownMode function.\nThe exploitation flow is as follows: An unauthenticated attacker initiates a series of 257 distinct POST requests to /api/user/login, each containing a unique, non-existent username. Because these usernames do not exist in the user store, the application records these as failed attempts. Each request contributes to the population of the internal mapping structure until the limit defined by MaxLoginAttemptRecords is reached.\nUpon reaching the threshold, the system triggers the global lockdown mechanism. Subsequent calls to IsAccountLocked verify this global state before performing individual credential validation. Consequently, even legitimate users attempting to authenticate are intercepted by this check and returned an HTTP 429 response. This denial-of-service condition remains effective for approximately 300 seconds by default, corresponding to the duration of auth.loginTimeout.\nThis attack vector does not affect existing authenticated sessions, as the session management layer remains independent of the login-path validation check. However, it renders the authentication interface unreachable for new sign-ins or re-authentications during the timeout window. The attacker can repeat this process indefinitely, ensuring persistent service unavailability. The vulnerability is fully resolved in version 5.1.0 by addressing how the lockdown logic interacts with the attempt tracking map."
}