CVE-2026-32245: Tinyauth Auth Bypass Vulnerability

CVE-2026-32245 Overview

CVE-2026-32245 is an authorization bypass vulnerability in Tinyauth, an authentication and authorization server. Prior to version 5.0.3, the OIDC token endpoint does not verify that the client exchanging an authorization code is the same client the code was originally issued to. This flaw allows a malicious OIDC client operator to exchange another client's authorization code using their own client credentials, obtaining tokens for users who never authorized their application.

This vulnerability directly violates RFC 6749 Section 4.1.3, which mandates that authorization servers must ensure the authorization code was issued to the authenticated confidential client or verify the client_id matches for public clients.

Critical Impact

Malicious OIDC client operators can impersonate users and gain unauthorized access to resources by hijacking authorization codes intended for legitimate applications.

Affected Products

• Tinyauth versions prior to 5.0.3

Discovery Timeline

• 2026-03-12 - CVE CVE-2026-32245 published to NVD
• 2026-03-12 - Last updated in NVD database

Technical Details for CVE-2026-32245

Vulnerability Analysis

This vulnerability is classified as CWE-863 (Incorrect Authorization). The core issue lies in the OIDC token endpoint's failure to bind authorization codes to specific clients during the token exchange process. In a properly implemented OAuth 2.0/OIDC flow, when a user authorizes an application, the authorization server generates a code that is cryptographically or logically bound to that specific client. During the token exchange, the server must verify this binding before issuing access tokens.

In vulnerable versions of Tinyauth, the GetCodeEntry function in the OIDC controller retrieves authorization codes without validating the requesting client's identity. This allows any authenticated OIDC client to exchange authorization codes that were issued to other clients, effectively bypassing the authorization model entirely.

Root Cause

The root cause is the missing client ID validation in the GetCodeEntry function call within the OIDC token endpoint. The vulnerable code retrieved authorization codes based solely on the code hash without verifying that the code was originally issued to the requesting client. This architectural oversight allows cross-client code exchange attacks.

Attack Vector

An attacker operating a malicious OIDC client registered with the Tinyauth server can exploit this vulnerability through the following attack scenario:

1. The attacker registers a legitimate-looking OIDC client with the Tinyauth server
2. A victim user authenticates and authorizes a different, legitimate OIDC client application
3. The attacker intercepts or obtains the authorization code (through phishing, network interception, or referrer leakage)
4. The attacker submits the stolen authorization code to the token endpoint using their own client credentials
5. Due to missing client validation, Tinyauth issues tokens to the attacker's client for the victim user
6. The attacker now has valid access tokens allowing them to impersonate the victim

The fix implemented in version 5.0.3 adds the client ID as a required parameter when retrieving code entries:

 
 	switch req.GrantType {
 	case "authorization_code":
-		entry, err := controller.oidc.GetCodeEntry(c, controller.oidc.Hash(req.Code))
+		entry, err := controller.oidc.GetCodeEntry(c, controller.oidc.Hash(req.Code), client.ClientID)
 		if err != nil {
 			if errors.Is(err, service.ErrCodeNotFound) {
 				tlog.App.Warn().Msg("Code not found")

Source: GitHub Commit Details

Detection Methods for CVE-2026-32245

Indicators of Compromise

• Token exchange requests where the client_id in the token request differs from the client_id that initiated the authorization flow
• Unusual patterns of authorization code usage across multiple client applications
• Users reporting unauthorized access to their accounts through applications they never authorized
• Multiple token requests for the same authorization code from different client credentials

Detection Strategies

• Implement logging that captures both the authorizing client_id and the exchanging client_id for all token requests
• Monitor for anomalies where authorization codes generated for one client are being exchanged by different clients
• Review OIDC audit logs for patterns of cross-client code exchange attempts
• Set up alerts for failed token exchanges that may indicate exploitation attempts

Monitoring Recommendations

• Enable verbose logging on the Tinyauth OIDC token endpoint to capture client identification details
• Implement real-time correlation between authorization requests and token exchange requests
• Monitor for spikes in authorization code exchange failures after upgrading, which may indicate blocked exploitation attempts
• Track user sessions for unauthorized application access patterns

How to Mitigate CVE-2026-32245

Immediate Actions Required

• Upgrade Tinyauth to version 5.0.3 or later immediately
• Audit recent token exchange logs for any signs of cross-client code exploitation
• Invalidate and rotate all existing authorization codes and refresh tokens as a precaution
• Notify users to review their authorized applications and revoke any suspicious access

Patch Information

The vulnerability is fixed in Tinyauth version 5.0.3. The patch modifies the GetCodeEntry function to require client ID validation during authorization code retrieval, ensuring codes can only be exchanged by the client they were originally issued to.

For detailed patch information, see the GitHub Security Advisory GHSA-xg2q-62g2-cvcm and the GitHub Release Version 5.0.3.

Workarounds

• If immediate upgrade is not possible, consider temporarily disabling OIDC functionality until the patch can be applied
• Implement additional network-level controls to restrict which clients can access the token endpoint
• Enable enhanced logging on the token endpoint to detect any exploitation attempts while awaiting upgrade
• Consider implementing a Web Application Firewall (WAF) rule to validate client_id consistency between authorization and token requests

# Upgrade Tinyauth to patched version
# Using container image
docker pull steveiliop56/tinyauth:5.0.3

# Or if building from source
git fetch --tags
git checkout v5.0.3