Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-09-21T17:18:52.770Z",
  "pubdate": "2026-09-21T17:18:52.770Z",
  "executiveSummary": "Tinyauth versions prior to 5.1.2 are vulnerable to an authentication and authorization bypass flaw stemming from improper case-sensitivity handling in hostname validation.\nThe vulnerability allows an authenticated, low-privilege user to circumvent per-application access control lists (ACLs) by requesting a target hostname with modified casing that is functionally equivalent but not explicitly recognized by the application's lookup logic.\nThe flaw manifests because reverse proxies typically route traffic case-insensitively, while Tinyauth performs lookups case-sensitively.\nWhen a mismatch occurs, the system fails to resolve the specific ACL, returning an empty access-control object. The proxy controller incorrectly interprets this empty object as permissive, granting unauthorized access to applications that should be restricted.\nThis vulnerability requires the attacker to be authenticated to the Tinyauth platform. Global allowlists and login-time restrictions remain intact; however, granular, per-app authorization checks are effectively neutralized for targeted applications.\nRisk is significant for environments relying on Tinyauth to manage fine-grained access to multiple backend services, as it allows privilege escalation by circumventing intended application-level security policies.",
  "technicalDetails": "The root cause of this vulnerability is a discrepancy in how hostnames are processed between the reverse proxy layer and the Tinyauth application logic. The reverse proxy processes incoming requests using case-insensitive hostname matching, while Tinyauth performs lookup operations for configured ACLs using case-sensitive string comparisons.\nThe vulnerability resides within the internal/service/access_controls_service.go file, specifically impacting the lookupStaticACLs and GetAccessControls functions. Additionally, the Docker-label lookup mechanism located in internal/service/docker_service.go (GetLabels) fails to handle case-normalization, leading to lookup failures when the provided hostname casing does not strictly match the stored configuration.\nWhen a request reaches the proxyHandler in internal/controller/proxy_controller.go, the system attempts to resolve access controls for the requested hostname. Because of the case-sensitivity mismatch, the lookup returns an empty access-control object rather than the expected restrictive policy or an error.\nThe security flaw in proxyHandler is the failure to distinguish between an 'empty' configuration and a 'no policy found' state. Upon receiving an empty access-control object, the controller defaults to an 'allow' state, effectively disabling all user, group, OAuth, LDAP, and IP-based restrictions for that specific app.\nThe attack flow proceeds as follows: First, an authenticated user identifies an application protected by restrictive ACLs. Second, the user crafts a request to the backend using an alternative casing for the hostname (e.g., 'App.Example.Com' instead of 'app.example.com'). Third, the reverse proxy routes the request to Tinyauth. Fourth, Tinyauth executes internal lookups, fails to find the case-sensitive key, and defaults to a null/empty ACL object. Finally, the proxy_controller treats the null object as permissive, granting the user access to the restricted resource.\nThis vulnerability is restricted to users who have already achieved an authenticated state within the platform. It does not allow for a full authentication bypass of the login mechanism itself, nor does it override global allowlists. However, once inside, it provides an effective mechanism to bypass authorization controls for specific applications that have been configured with restricted access policies.\nAffected versions are strictly those prior to 5.1.2. The issue is resolved by ensuring normalization of hostname inputs before lookup operations, ensuring that the application logic aligns with the behavior of the network infrastructure."
}