CVE-2026-77560
HighCVSS 8.1Summary
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.
Risk Assessment
A low-privilege user can gain access to applications that should exclude them, undermining per-app access control enforcement.
Recommendation
Update Tinyauth to version 5.1.2 or later. Until patched, consider normalizing hostname case at the reverse proxy layer.
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-77561Medium
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.
Original NVD description (English source)
Tinyauth is an authentication and authorization server. Prior to 5.1.2, Tinyauth compares forwarded hostnames 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 in internal/service/access_controls_service.go through lookupStaticACLs and GetAccessControls, and the Docker-label fallback in internal/service/docker_service.go through GetLabels, can miss the configured app and return an empty access-control object. internal/controller/proxy_controller.go proxyHandler then treats the empty user, group, OAuth, LDAP, and IP restrictions as permissive and returns an authenticated result for an app that should exclude the user. Unauthenticated users remain subject to login, and global login-time allowlists are not bypassed. This issue is fixed in version 5.1.2.