tinyauth Authorization Bypass via Case-Sensitive Hostname Matching

tinyauth is a forward-auth service that acts as a gatekeeper for reverse proxies like Traefik, Caddy, Nginx, and Envoy. It verifies authentication and enforces per-app access control lists (ACLs) based on hostnames. An authorization bypass exists in tinyauth versions prior to 5.1.2 due to case-sensitive string comparisons when matching incoming hostnames against configured ACLs.

Because DNS, HTTP routing, and TLS treat hostnames as case-insensitive, a reverse proxy will correctly route a mixed-case hostname (e.g., APP.example.com) to the intended application. However, when tinyauth receives this request, its lookup logic fails to match the hostname because it performs a case-sensitive comparison. When the lookup fails, the application incorrectly falls back to an empty configuration object instead of denying access. This "fail-open" behavior grants authorized status to any already-authenticated user, effectively ignoring any per-app users, groups, or ip allowlists. This vulnerability allows an attacker with a valid session to bypass intended access restrictions for any protected app on the same instance.

Attack Chain

1. Attacker obtains a valid user session for the target tinyauth instance.
2. Attacker identifies a target application protected by an ACL that explicitly excludes their user account or group.
3. Attacker crafts an HTTP request for the target application using a mixed-case hostname (e.g., TargetApp.Example.Com instead of targetapp.example.com).
4. The reverse proxy receives the request, ignores the case difference, and routes it to the intended upstream backend.
5. The proxy sends the request to tinyauth via the configured forward-auth endpoint, preserving the mixed-case hostname in the X-Forwarded-Host or Host header.
6. tinyauth's GetAccessControls function attempts to lookup the mixed-case hostname, fails to find a match due to case-sensitive logic, and returns an empty App configuration.
7. The authorization logic evaluates the empty configuration, defaults to "allow," and returns a 200 Authenticated response to the reverse proxy.
8. The proxy forwards the request to the upstream application, treating the attacker as an authorized user.

Impact

Successful exploitation allows any authenticated user to bypass per-app access restrictions, gaining full access to the data and functionality of restricted applications. This defeats the product's primary security feature - the per-app trust boundary - within multi-app SSO deployments. Impacted sectors include any organization relying on tinyauth to manage granular access to internal services.

Recommendation

1. Upgrade tinyauth to version 5.1.2 or later immediately to resolve the case-insensitive matching logic.
2. Audit application access logs for unexpected 200 OK responses from the forward-auth endpoint that correspond to known restricted users accessing sensitive subdomains.
3. Validate that your reverse proxy configuration and tinyauth instance are correctly synchronized regarding expected domain case-sensitivity.