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
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/steveiliop56/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/steveiliop56/tinyauth < 1.0.1-0.20260401140714-fc1d4f2082a5
Fixed in
1.0.1-0.20260401140714-fc1d4f2082a5· Vendor fix available
Issue
All three OAuth service implementations (GenericOAuthService, GithubOAuthService, GoogleOAuthService) store PKCE verifiers and access tokens as mutable struct fields on singleton instances shared across all concurrent requests. When two users initiate OAuth login for the same provider concurrently, a race condition between VerifyCode() and Userinfo() causes one user to receive a session with the other user's identity. Details The OAuthBrokerService.GetService() returns a single shared instance per provider for every request. The OAuth flow stores intermediate state as struct fields on this singleton: Token storage — genericoauthservice.go line 96: Verifier storage — genericoauthservice.go line 81: In the callback handler oauthcontroller.go lines 136–143, the code calls: Between these two calls, a concurrent request's VerifyCode() can overwrite the token field, causing GetUser() → Userinfo() to fetch the wrong user's identity claims. The same pattern exists in all three…
Recommended action: Upgrade to 1.0.1-0.20260401140714-fc1d4f2082a5 (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/steveiliop56/tinyauth < 1.0.1-20260311144920-9eb2d33064b7
Fixed in
1.0.1-20260311144920-9eb2d33064b7· Vendor fix available
Issue
The OIDC authorization endpoint allows users with a TOTP-pending session (password verified, TOTP not yet completed) to obtain authorization codes. An attacker who knows a user's password but not their TOTP secret can obtain valid OIDC tokens, completely bypassing the second factor. Details When a user with TOTP enabled logs in at POST /api/user/login, the server creates a session with TotpPending: true and returns a session cookie. The context middleware (internal/middleware/contextmiddleware.go:56-66) correctly sets TotpPending: true and does not set IsLoggedIn for these sessions. However, the OIDC authorize handler (internal/controller/oidccontroller.go:105-116) only checks whether a user context exists via utils.GetContext(c). It does not check IsLoggedIn or TotpPending. Since the context middleware populates a context for TOTP-pending sessions (with the username filled in), GetContext succeeds, and the handler proceeds to issue an authorization code at line 156 using the…
Recommended action: Upgrade to 1.0.1-20260311144920-9eb2d33064b7 (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/steveiliop56/tinyauth < 1.0.1-20260311144920-9eb2d33064b7
Fixed in
1.0.1-20260311144920-9eb2d33064b7· Vendor fix available
Issue
The OIDC token endpoint does not verify that the client exchanging an authorization code is the same client the code was issued to. A malicious OIDC client operator can exchange another client's authorization code using their own client credentials, obtaining tokens for users who never authorized their application. This violates RFC 6749 Section 4.1.3. Details When an authorization code is created, StoreCode at internal/service/oidcservice.go:305-322 correctly stores the ClientID alongside the code hash in the database (line 316). During token exchange at internal/controller/oidccontroller.go:267-309, the handler retrieves the code entry at line 268 and validates the redirecturi at line 291, but never compares entry.ClientID against the requesting client's ID (creds.ClientID). The code proceeds directly to GenerateAccessToken at line 299. The developers clearly intended this check to exist, the refresh token flow at internal/service/oidcservice.go:508-510 has the exact guard:…
Recommended action: Upgrade to 1.0.1-20260311144920-9eb2d33064b7 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.