CVE-2026-77561: Tinyauth: Unauthenticated login attempts can trigger global login lockdown denial of service
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/usercontroller.go loginHandler passes each attacker-controlled identifier to internal/service/authservice.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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Tinyauthto a version that resolves this vulnerability.Fixed in 5.1.0
Event History
Frequently Asked Questions
Who is exposed to this denial-of-service condition?
Tinyauth deployments running versions before 5.1.0 are exposed because an unauthenticated remote attacker can reach the login endpoint. Existing authenticated sessions remain valid, but users attempting new logins can be blocked.
What does an attacker need to trigger the lockdown?
The attacker needs only network access to send POST requests to /api/user/login. They can use 257 distinct nonexistent usernames to fill the login-attempt record limit; no account or authentication is required.
How long are legitimate logins blocked, and can the attack persist?
Valid users receive HTTP 429 while the global lockdown is active, until auth.loginTimeout expires. The default timeout is approximately 300 seconds, and an attacker can repeat the requests to trigger lockdown again.
What should administrators do if they cannot upgrade immediately?
Restrict or rate-limit unauthenticated access to POST /api/user/login to reduce an attacker's ability to submit large numbers of distinct nonexistent usernames. Upgrade to Tinyauth 5.1.0 when possible.
How can administrators recognize that the issue is being exploited?
Look for a burst of login requests using many distinct nonexistent usernames, followed by HTTP 429 responses for otherwise unrelated valid-account login attempts. Authenticated users may continue using their existing sessions during the event.