CVE-2026-77561
MediumCVSS 5.3Summary
Tinyauth prior to 5.1.0 allows an unauthenticated remote attacker to send POST /api/user/login requests with 257 distinct nonexistent usernames to fill MaxLoginAttemptRecords and activate a global login lockdown. IsAccountLocked checks that global state before validating unrelated accounts, causing valid users to receive HTTP 429 for approximately 300 seconds.
Risk Assessment
An attacker can trigger a global login lockdown and prevent valid users from accessing the service. The attack can be repeated, although existing authenticated sessions are not invalidated.
Recommendation
Update Tinyauth to version 5.1.0 or later, which fixes the global login lockdown. Consider IP-based login attempt throttling and monitoring for unusual patterns.
Other vulnerabilities in Tinyauth
See all- CVE-2026-77582Medium
Tinyauth prior to 5.1.0 exposes a remotely observable timing difference between authentication attempts for existing and nonexistent local usernames. The loginHandler and basicAuth functions return quickly after a missing user is reported, while an existing user causes bcrypt password verification work.
- CVE-2026-77560High
In Tinyauth prior to 5.1.2, forwarded hostnames are compared case-sensitively while reverse proxies route equivalent hostnames case-insensitively, allowing an authenticated low-privilege user to bypass per-app access controls with a differently cased hostname. The lookup can miss the configured app and return an empty access-control object, which is then treated as permissive.
Original NVD description (English source)
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.