Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/tinyauthapp/tinyauth < 1.0.1-0.20260715123057-dade1e2c8f27
Fixed in
1.0.1-0.20260715123057-dade1e2c8f27· Vendor fix available
Issue
Tinyauth's login rate-limit bookkeeping can enter a global lockdown mode when its in-memory login-attempt map reaches 256 distinct identifiers. Because unauthenticated POST /api/user/login requests for unknown usernames are recorded in this same map, a remote unauthenticated attacker can submit 257 unique bogus usernames and cause valid credentials for unrelated users to be treated as locked until auth.loginTimeout expires. This was confirmed against the stable v5.0.7 release. With default configuration, auth.loginTimeout is 300 seconds and auth.loginMaxRetries is 3, so the denial lasts about 5 minutes and can be repeated. Details In stable v5.0.7, the login endpoint is registered at internal/controller/usercontroller.go:45 and accepts unauthenticated JSON credentials in loginHandler at internal/controller/usercontroller.go:50. Before validating credentials, it calls controller.auth.IsAccountLocked(req.Username) at internal/controller/usercontroller.go:65. When a username…
Recommended action: Upgrade to 1.0.1-0.20260715123057-dade1e2c8f27 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/tinyauthapp/tinyauth < 1.0.1-0.20260720133915-80bc87188ec3
Fixed in
1.0.1-0.20260720133915-80bc87188ec3· Vendor fix available
Issue
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 GitHub Advisory Details (form fields — paste-ready) Affected products | Field | Value | |-------|-------| | Ecosystem | Other (self-hosted) / Go | | Package name | github.com/steveiliop56/tinyauth (forward-auth middleware) | | Affected versions | < 5.1.2 | | Patched versions | 5.1.2 | Advisory details | Field | Value | |-------|-------| | Title | tinyauth forward-auth authorization bypass: per-app ACL host matching is case-sensitive while hostnames are case-insensitive, so a mixed-case host defeats users/groups/ip allowlists and fails open | - Status: Runtime-confirmed (local lab, 127.0.0.1 only) - Target: steveiliop56/tinyauth v5.0.7 (commit 479f1657812b7bf01438607464dedaa148155301); root cause also present on main HEAD - Component: internal/service/accesscontrolsservice.go (lookupStaticACLs /…
Recommended action: Upgrade to 1.0.1-0.20260720133915-80bc87188ec3 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/tinyauthapp/tinyauth < 1.0.1-0.20260714134959-c22925c2fba9
Fixed in
1.0.1-0.20260714134959-c22925c2fba9· Vendor fix available
Issue
It's possible to enumerate users through a timing oracle. In other words: I can easily check if a username exists or not by observing the timing differences between logins. PoC Setup a tinyauth server with a local user. It can be over the network. Try to log in with the local user, using an incorrect password: there is a noticeable delay. You know that the user exists. Now try to log in with a username that does not exist, using an incorrect password: it will complete almost immediately. You know that the user does not exist. Expected vs actual behavior Login attempts should take roughly the same amount of time when the user exists vs when the user does not exist. Right now, nonexistent user attempts are way faster, meaning if your login attempt is slow, then the username exists for sure. Details Existing usernames will take an extra ~50 milliseconds to respond to login attempts, while non-existing usernames will take only ~50 microseconds (1000x less time) to return an…
Recommended action: Upgrade to 1.0.1-0.20260714134959-c22925c2fba9 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.