CVE-2026-77560: Tinyauth: forward-auth per-app ACL is matched case-sensitively against the (case-insensitive) hostname, letting an authenticated user reach apps they are not on the allowlist for
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/accesscontrolsservice.go through lookupStaticACLs and GetAccessControls, and the Docker-label fallback in internal/service/dockerservice.go through GetLabels, can miss the configured app and return an empty access-control object. internal/controller/proxycontroller.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.
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.2
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker must already be authenticated to Tinyauth as a low-privilege user. Unauthenticated users still have to log in, and global login-time allowlists are not bypassed.
What configuration is affected?
Deployments using per-application access controls are affected when a reverse proxy forwards a hostname with different letter casing than the hostname used by Tinyauth's ACL lookup. This can affect both static ACL lookup and the Docker-label fallback.
What access can an attacker gain?
An authenticated user can reach an application for which they are not included in the per-app allowlist. The bypass can evade configured user, group, OAuth, LDAP, and IP restrictions when the mismatched hostname causes Tinyauth to use an empty, permissive access-control object.
How can this be remediated?
Upgrade Tinyauth to version 5.1.2, which fixes the issue. If an immediate upgrade is not possible, ensure forwarded hostnames use the same casing as the hostnames configured for per-app ACLs.