Tinyauth vulnerabilities

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.

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.

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.