CVE-2026-33544 Overview
CVE-2026-33544 is a race condition vulnerability in Tinyauth, an authentication and authorization server. Prior to version 5.0.5, all three OAuth service implementations (GenericOAuthService, GithubOAuthService, GoogleOAuthService) store PKCE verifiers and access tokens as mutable struct fields on singleton instances shared across all concurrent requests. When two users initiate OAuth login for the same provider concurrently, a race condition between VerifyCode() and Userinfo() causes one user to receive a session with the other user's identity, enabling account takeover.
Critical Impact
This vulnerability allows attackers to hijack user sessions during concurrent OAuth login flows, potentially gaining unauthorized access to another user's authenticated session and identity.
Affected Products
- Tinyauth versions prior to 5.0.5
- All OAuth provider integrations (Generic OAuth, GitHub OAuth, Google OAuth)
- Deployments with concurrent user authentication activity
Discovery Timeline
- 2026-04-02 - CVE-2026-33544 published to NVD
- 2026-04-02 - Last updated in NVD database
Technical Details for CVE-2026-33544
Vulnerability Analysis
This vulnerability represents a classic race condition flaw (CWE-362) in the OAuth authentication flow. The core issue stems from the use of singleton service instances that store mutable state (PKCE verifiers and access tokens) as struct fields rather than per-request isolated storage.
In a typical OAuth flow, the PKCE (Proof Key for Code Exchange) verifier is generated during the authorization request and must be securely associated with the specific user session that initiated it. The access token obtained after successful code verification must similarly remain bound to the correct user context.
When these values are stored as mutable fields on a shared singleton instance, concurrent OAuth login requests from different users can overwrite each other's state. This creates a Time-of-Check Time-of-Use (TOCTOU) window where:
- User A initiates OAuth login, storing their PKCE verifier in the singleton
- User B initiates OAuth login for the same provider, overwriting User A's verifier
- User A's VerifyCode() completes but now uses User B's verifier context
- User A receives a session authenticated as User B
The attack requires no special privileges and can occur naturally in multi-user environments with moderate concurrent authentication activity.
Root Cause
The root cause is improper state management in the OAuth service implementations. By storing request-specific authentication state (PKCE verifiers and access tokens) as mutable struct fields on singleton service instances shared across all requests, the application violates the principle of request isolation. Each authentication flow should maintain its own isolated state context to prevent cross-request contamination.
Attack Vector
The attack vector is network-based and requires two conditions to be met: the attacker must be a low-privileged user capable of initiating OAuth authentication, and there must be a concurrent OAuth login attempt from another user targeting the same provider. The race condition occurs during the OAuth callback processing between the VerifyCode() and Userinfo() function calls. While the attack requires some user interaction and has high complexity due to the timing-dependent nature, successful exploitation results in complete identity takeover with high confidentiality and integrity impact.
The following patch demonstrates how the fix introduces session-based OAuth state isolation:
type BootstrapApp struct {
config config.Config
context struct {
- appUrl string
- uuid string
- cookieDomain string
- sessionCookieName string
- csrfCookieName string
- redirectCookieName string
- users []config.User
- oauthProviders map[string]config.OAuthServiceConfig
- configuredProviders []controller.Provider
- oidcClients []config.OIDCClientConfig
+ appUrl string
+ uuid string
+ cookieDomain string
+ sessionCookieName string
+ csrfCookieName string
+ redirectCookieName string
+ oauthSessionCookieName string
+ users []config.User
+ oauthProviders map[string]config.OAuthServiceConfig
+ configuredProviders []controller.Provider
+ oidcClients []config.OIDCClientConfig
}
services Services
}
Source: GitHub Commit f26c217
The patch adds a dedicated oauthSessionCookieName field to properly isolate OAuth flow state per session rather than sharing state across the singleton instance.
Detection Methods for CVE-2026-33544
Indicators of Compromise
- Unexpected session authentication events where users report being logged in as different users
- Authentication logs showing concurrent OAuth callbacks for the same provider with session assignment anomalies
- User complaints of account access by unauthorized parties following OAuth login attempts
- Audit trails indicating identity mismatches between OAuth provider responses and resulting session ownership
Detection Strategies
- Implement correlation monitoring between OAuth callback timestamps and session creation events to identify timing anomalies
- Monitor for multiple concurrent OAuth authorization requests to the same provider within short time windows
- Enable verbose logging on OAuth service components to capture PKCE verifier and token state transitions
- Deploy SentinelOne Singularity for real-time detection of unauthorized session access patterns and identity anomalies
Monitoring Recommendations
- Enable detailed audit logging for all OAuth authentication flows including PKCE verifier generation and verification
- Implement alerting on session assignment events where the authenticated identity differs from the initiating request context
- Monitor application logs for concurrent OAuth callback processing events within race condition time windows
- Track user session authentication patterns to identify anomalous identity switching behavior
How to Mitigate CVE-2026-33544
Immediate Actions Required
- Upgrade Tinyauth to version 5.0.5 or later immediately
- Review authentication logs for any evidence of session hijacking during concurrent OAuth flows
- Force re-authentication for all active sessions to ensure proper identity binding
- Notify users who performed OAuth login during periods of high concurrent activity to verify account integrity
Patch Information
The vulnerability has been patched in Tinyauth version 5.0.5. The fix refactors the OAuth flow to use session-based state storage rather than singleton mutable fields, ensuring proper isolation of PKCE verifiers and access tokens between concurrent requests. The patch commit can be reviewed at the GitHub Commit and the release is available at Tinyauth v5.0.5. For detailed technical analysis, refer to the GitHub Security Advisory GHSA-9q5m-jfc4-wc92.
Workarounds
- Temporarily disable OAuth authentication providers and use alternative authentication methods until patching is complete
- Implement request rate limiting on OAuth callback endpoints to reduce concurrent processing likelihood
- Deploy authentication behind a load balancer configured to serialize OAuth callback requests per provider
- Enable user session validation requiring re-verification of identity after OAuth completion
# Configuration example - Disable OAuth providers temporarily until patched
# In Tinyauth configuration file, disable OAuth providers:
# oauth:
# enabled: false
# providers: []
# Alternatively, implement rate limiting at reverse proxy level
# nginx configuration example:
limit_req_zone $binary_remote_addr zone=oauth_limit:10m rate=1r/s;
location /api/oauth/callback {
limit_req zone=oauth_limit burst=1 nodelay;
proxy_pass http://tinyauth_backend;
}
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
