CVE-2026-32245
Authorization Code Confusion in Tinyauth OIDC Token Endpoint
Publication date: 2026-03-12
Last updated on: 2026-03-19
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| tinyauth | tinyauth | to 5.0.2 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-863 | The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': "This vulnerability exists in the Tinyauth authentication and authorization server's OpenID Connect (OIDC) implementation prior to version 5.0.3. The issue is that the OIDC token endpoint does not verify that the client exchanging an authorization code is the same client to which the code was originally issued."}, {'type': 'paragraph', 'content': "Because of this, a malicious client operator can use their own client credentials to exchange another client's authorization code, thereby obtaining tokens (access, ID, and refresh tokens) for users who never authorized their application. This violates the OAuth 2.0 specification (RFC 6749 Section 4.1.3) and leads to unauthorized token issuance."}, {'type': 'paragraph', 'content': 'The vulnerability was fixed by adding strict client ID validation during the token exchange process, ensuring that authorization codes can only be exchanged by the client they were issued to.'}] [1, 2]
How can this vulnerability impact me? :
[{'type': 'paragraph', 'content': 'This vulnerability can allow an attacker who operates a malicious OIDC client to impersonate users of other clients on the same Tinyauth instance.'}, {'type': 'paragraph', 'content': "Specifically, the attacker can exchange another client's authorization code using their own client credentials and obtain tokens for users who never authorized their application."}, {'type': 'list_item', 'content': 'User impersonation across different OIDC clients.'}, {'type': 'list_item', 'content': 'Unauthorized access to user tokens, potentially compromising user data and session integrity.'}, {'type': 'list_item', 'content': 'Violation of expected authorization flows, leading to security breaches.'}, {'type': 'paragraph', 'content': "However, this attack requires a multi-client deployment and the ability to obtain another client's authorization code, which may be leaked through URL query parameters, referrer headers, browser history, or logs. Single-client deployments are not affected."}] [2]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': "This vulnerability involves improper validation of client IDs during the OIDC token exchange process, allowing a malicious client to exchange another client's authorization code. Detection would involve monitoring token exchange requests to identify if authorization codes are being exchanged by clients other than those to which the codes were originally issued."}, {'type': 'paragraph', 'content': 'Specifically, you can look for HTTP 400 responses with an "invalid_client" error at the OIDC token endpoint, which indicates the server is rejecting token requests due to client ID mismatches (as per the fix).'}, {'type': 'paragraph', 'content': 'Since the vulnerability is related to the OIDC token endpoint, network monitoring tools or logs can be inspected for unusual token exchange patterns, such as authorization codes being used by different client credentials.'}, {'type': 'paragraph', 'content': 'No explicit detection commands are provided in the available resources.'}] [1, 2]
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation step is to upgrade Tinyauth to version 5.0.3 or later, where this vulnerability has been fixed by enforcing strict client ID validation during the OIDC token exchange.
This update ensures that the authorization code can only be exchanged by the client to which it was originally issued, preventing unauthorized token issuance.
Additionally, reviewing your deployment to ensure that multiple OIDC clients do not share overlapping redirect URIs or that authorization codes are not leaked via URL query parameters, referrer headers, browser history, or logs can reduce risk.
Until the update is applied, monitor token exchange requests for suspicious activity and consider restricting access to the token endpoint to trusted clients only.