CVE-2026-32246: TOTP Authentication Bypass in Tinyauth OIDC Controller

Tinyauth functions as an authentication and authorization server, commonly deployed as an identity provider (IdP) for internal or external applications. It supports OpenID Connect (OIDC) to federate identity and relies on multi-factor authentication (MFA), specifically Time-based One-Time Passwords (TOTP), to secure user accounts. The vulnerability, tracked as CVE-2026-32246, resides within the OIDC controller responsible for handling authorization code requests.

The root of the issue is a state management logic flaw categorized under CWE-287 (Improper Authentication) and CWE-306 (Missing Authentication for Critical Function). When a user successfully authenticates with their primary credentials but requires a second factor, the system places their session into an intermediate state. The OIDC endpoint fails to properly differentiate between this intermediate state and a fully authenticated state, allowing requests to proceed prematurely.

Exploitation of this vulnerability requires the attacker to possess the victim's valid username and password. Once authenticated to the first phase, the attacker can interact directly with the OIDC authorization endpoint to bypass the TOTP prompt. The resulting impact is the unauthorized issuance of OIDC tokens, granting the attacker full access to relying parties configured to trust the vulnerable Tinyauth instance.

Tinyauth implements a multi-stage authentication state machine to handle MFA requirements. In Phase 1, the server verifies the provided username and password. If the credentials are correct and TOTP is enabled, the server initializes a session where the boolean flag TotpPending is set to true and IsLoggedIn is set to false. In Phase 2, the server verifies the submitted TOTP code, subsequently removing the TotpPending flag and toggling IsLoggedIn to true.

The application utilizes a global middleware component, context_middleware, designed to attach a user context object to incoming HTTP requests. This middleware intentionally populates the user context even for sessions in the Phase 1 intermediate state. This design choice allows the server to identify the user for the purpose of rendering the specific TOTP verification user interface and processing the subsequent MFA submission.

The vulnerability manifests in the internal/controller/oidc_controller.go file, specifically within the /api/oidc/authorize handler. This handler retrieves the user context via utils.GetContext(c) and verifies its existence to authorize the OIDC flow. However, the handler omits the critical verification of the IsLoggedIn boolean flag, erroneously trusting any populated context object regardless of its pending MFA status.

The original implementation of the OIDC controller assumed that the presence of a user context inherently implied a fully authenticated session. The vulnerable logic retrieved the context and proceeded directly to processing the authorization request. This assumption broke down due to the middleware's behavior of populating the context for users in the TotpPending state.

The official patch applied in commit f1e869a92045cb24a93cc07be8e2253f649e0961 corrects this logic by introducing a strict verification of the IsLoggedIn property. The added code block explicitly returns an authorization error if the user context exists but the boolean flag remains false. This ensures the OIDC flow terminates before evaluating the requested scopes or issuing an authorization code.

@@ -115,6 +115,11 @@ func (controller *OIDCController) Authorize(c *gin.Context) {
 		return
 	}
 
+	if !userContext.IsLoggedIn {
+		controller.authorizeError(c, errors.New("err user not logged in"), "User not logged in", "The user is not logged in", "", "", "")
+		return
+	}
+
 	var req service.AuthorizeRequest

In addition to the primary OIDC fix, secondary hardening was introduced via commit b2a1bfb1f532e87f205fa3afa3fc9f148c53ab89. This commit addresses a similar structural weakness in the Basic Authentication flow by explicitly denying Basic Auth requests if the target user has a configured TOTP secret. Furthermore, the commit bolsters the token exchange endpoint by ensuring the client_id requesting the exchange matches the entity originally associated with the authorization code.

Exploitation begins with the attacker acquiring the victim's valid username and password. The attacker submits these credentials to the /api/user/login endpoint. The server validates the credentials, notes the configured TOTP requirement, and returns a session cookie representing the intermediate TotpPending state.

Instead of interacting with the provided TOTP challenge interface, the attacker retains the issued session cookie and initiates a standard OIDC authorization request. The attacker crafts a GET request to /api/oidc/authorize, specifying a valid client_id, redirect_uri, and the desired response_type=code. The attacker includes the intermediate session cookie in the HTTP headers of this request.

The vulnerable Tinyauth server processes the request, identifies the user context attached by the middleware, and incorrectly authorizes the transaction. The server redirects the attacker to the specified redirect_uri with a valid OIDC authorization code appended to the URL query parameters. The attacker intercepts this code to prevent the standard application flow from consuming it prematurely.

In the final exploitation phase, the attacker submits the intercepted authorization code to the /api/oidc/token endpoint. The server exchanges the code for a set of functional OIDC tokens, including an Access Token and an ID Token. The attacker presents these tokens to the downstream relying party, successfully impersonating the victim without ever supplying the required TOTP code.

The exploitation of CVE-2026-32246 results in a complete bypass of the multi-factor authentication mechanisms for services protected by Tinyauth. The primary consequence is the unauthorized issuance of identity tokens. These tokens carry the authenticated state of the victim and are implicitly trusted by downstream relying parties, granting the attacker the exact privileges assigned to the compromised user.

The vulnerability is assessed with a CVSS v3.1 base score of 8.5 (High), calculated via the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N. The requirement for low privileges (PR:L) reflects the necessity of possessing the victim's primary password. The changed scope (S:C) indicates that the impact bridges from the authentication server itself to the connected downstream applications.

This vulnerability fundamentally undermines the security guarantees of deploying an identity provider. Organizations utilizing Tinyauth to enforce zero-trust access controls or to comply with regulatory mandates requiring MFA are exposed to significant risk. Attackers leveraging compromised credentials from external breaches can trivially bypass the secondary defensive layer, leading to unauthorized data access and system manipulation.

The primary and most effective remediation strategy is to upgrade the Tinyauth deployment to version 5.0.3 or later. This release contains the authoritative patches addressing both the OIDC controller bypass and the associated Basic Authentication weaknesses. System administrators must ensure the application binary is replaced and the service restarted to apply the new logic.

If immediate patching is not feasible due to change management constraints, organizations should monitor network traffic or web application firewalls for anomalous OIDC flows. Specifically, security teams should look for requests to /api/oidc/authorize originating from IP addresses or user agents that have not recently generated successful TOTP verification events. While this does not prevent the attack, it provides critical visibility into potential exploitation attempts.

Following the application of the patch, organizations should conduct a retroactive threat hunting exercise. Security teams must analyze Tinyauth server logs to identify any user sessions that transitioned from a password login directly to an OIDC authorization grant without an intervening TOTP validation. If suspicious activity is detected, incident responders should mandate a password reset for the affected user, rotate their TOTP secret, and immediately revoke all active OIDC tokens and sessions.