Tinyauth
Monthly
Authorization bypass in Tinyauth releases prior to 5.1.2 allows an authenticated, low-privilege user to reach applications whose per-app access controls are configured to exclude them. Tinyauth matches forwarded hostnames case-sensitively in lookupStaticACLs/GetAccessControls and in the Docker-label fallback (GetLabels), while nginx, Traefik, and Caddy route hostnames case-insensitively; requesting the target app with a differently-cased hostname therefore misses the configured policy, returns an empty access-control object, and proxyHandler treats the empty user/group/OAuth/LDAP/IP restrictions as permissive. Exploitation requires valid low-privilege credentials (CVSS PR:L) and a deployment that enforces per-app ACLs behind a case-insensitive proxy; unauthenticated visitors are still stopped at login and global login-time allowlists are not bypassed. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and the vendor-released fix is version 5.1.2.
Tinyauth versions prior to 5.1.0 can be forced into a temporary, instance-wide login lockdown by an unauthenticated remote attacker who sends POST /api/user/login requests using 257 distinct nonexistent usernames, filling the MaxLoginAttemptRecords limit so that legitimate users receive HTTP 429 responses until the default auth.loginTimeout of roughly 300 seconds elapses. The flaw is an availability-only, low-severity issue (CVSS 3.1 5.3, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L; CWE-307) that grants no confidentiality or integrity access and does not invalidate or degrade existing authenticated sessions; the attacker gains nothing beyond the temporary denial of new logins and must repeat the request burst to sustain it. No public exploit code was identified at time of analysis, and there is no evidence of active exploitation (not in CISA KEV); deployments that have disabled lockdown mode are unaffected. The issue is fixed in Tinyauth 5.1.0.
Username enumeration is possible against Tinyauth instances running versions before 5.1.0 because the local-user login handler and the HTTP basic-auth middleware return as soon as an account is reported missing, while an existing account triggers a comparatively slow bcrypt password verification, leaving a remotely measurable timing discrepancy (CWE-208). Unauthenticated attackers with network reach to the authentication endpoints can take repeated latency measurements and statistically distinguish valid local usernames from invalid ones; the independent assessment rates this CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N, so the outcome is limited to disclosure of valid usernames with no direct password, session, or data compromise, and exploitation is constrained by network/server jitter requiring many samples. Deployments that authenticate exclusively through external OAuth/OIDC providers and maintain no local users do not exercise the vulnerable bcrypt path, and no public exploit code was identified at time of analysis; the vendor-released fix is version 5.1.0.
Authorization bypass in Tinyauth releases prior to 5.1.2 allows an authenticated, low-privilege user to reach applications whose per-app access controls are configured to exclude them. Tinyauth matches forwarded hostnames case-sensitively in lookupStaticACLs/GetAccessControls and in the Docker-label fallback (GetLabels), while nginx, Traefik, and Caddy route hostnames case-insensitively; requesting the target app with a differently-cased hostname therefore misses the configured policy, returns an empty access-control object, and proxyHandler treats the empty user/group/OAuth/LDAP/IP restrictions as permissive. Exploitation requires valid low-privilege credentials (CVSS PR:L) and a deployment that enforces per-app ACLs behind a case-insensitive proxy; unauthenticated visitors are still stopped at login and global login-time allowlists are not bypassed. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and the vendor-released fix is version 5.1.2.
Tinyauth versions prior to 5.1.0 can be forced into a temporary, instance-wide login lockdown by an unauthenticated remote attacker who sends POST /api/user/login requests using 257 distinct nonexistent usernames, filling the MaxLoginAttemptRecords limit so that legitimate users receive HTTP 429 responses until the default auth.loginTimeout of roughly 300 seconds elapses. The flaw is an availability-only, low-severity issue (CVSS 3.1 5.3, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L; CWE-307) that grants no confidentiality or integrity access and does not invalidate or degrade existing authenticated sessions; the attacker gains nothing beyond the temporary denial of new logins and must repeat the request burst to sustain it. No public exploit code was identified at time of analysis, and there is no evidence of active exploitation (not in CISA KEV); deployments that have disabled lockdown mode are unaffected. The issue is fixed in Tinyauth 5.1.0.
Username enumeration is possible against Tinyauth instances running versions before 5.1.0 because the local-user login handler and the HTTP basic-auth middleware return as soon as an account is reported missing, while an existing account triggers a comparatively slow bcrypt password verification, leaving a remotely measurable timing discrepancy (CWE-208). Unauthenticated attackers with network reach to the authentication endpoints can take repeated latency measurements and statistically distinguish valid local usernames from invalid ones; the independent assessment rates this CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N, so the outcome is limited to disclosure of valid usernames with no direct password, session, or data compromise, and exploitation is constrained by network/server jitter requiring many samples. Deployments that authenticate exclusively through external OAuth/OIDC providers and maintain no local users do not exercise the vulnerable bcrypt path, and no public exploit code was identified at time of analysis; the vendor-released fix is version 5.1.0.