CVE-2026-33544

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.

Details

The OAuthBrokerService.GetService() returns a single shared instance per provider for every request. The OAuth flow stores intermediate state as struct fields on this singleton:

Token storage, generic_oauth_service.go line 96:

generic.token = token  // Shared mutable field on singleton

Verifier storage, generic_oauth_service.go line 81:

generic.verifier = verifier  // Shared mutable field on singleton

In the callback handler oauth_controller.go lines 136–143, the code calls:

err = service.VerifyCode(code)                       // line 136, stores token on singleton
// ... race window ...
user, err := controller.broker.GetUser(req.Provider)  // line 143, reads token from singleton

Between these two calls, a concurrent request's VerifyCode() can overwrite the token field, causing GetUser() → Userinfo() to fetch the wrong user's identity claims.

The same pattern exists in all three implementations:

• github_oauth_service.go lines 34–39, 77, 86–99
• google_oauth_service.go lines 22–27, 65, 73–87

PoC

Race scenario (two concurrent OAuth callbacks):

1. User A and User B both click "Login with GitHub" on the same tinyauth instance
2. Both are redirected to GitHub, authorize, and GitHub redirects both back with authorization codes
3. Both callbacks arrive at tinyauth nearly simultaneously:

Timeline:
  t0: Request A → service.VerifyCode(codeA) → singleton.token = tokenA
  t1: Request B → service.VerifyCode(codeB) → singleton.token = tokenB  (overwrites tokenA)
  t2: Request A → broker.GetUser("github")  → Userinfo() reads singleton.token = tokenB
  t3: Request A receives User B's identity (email, name, groups)

User A now has a tinyauth session with User B's email, gaining access to all resources User B is authorized for via tinyauth's ACL.

PKCE verifier DoS variant: Even with PKCE, concurrent oauthURLHandler calls overwrite the verifier field, causing VerifyCode() to send the wrong verifier to the OAuth provider, which rejects the exchange.

Static verification: Run Go's race detector on a test that calls VerifyCode and Userinfo concurrently on the same service instance, the -race flag will flag data races on the token and verifier fields.

Go race detector confirmation: Running a concurrent test with go test -race on the singleton service detects 4 data races on the token and verifier fields. Without the race detector, measured token overwrite rate is 99.9% (9,985/10,000 iterations).

Test environment: tinyauth v5.0.4, commit 592b7ded, Go race detector + source code analysis

An attacker who times their OAuth callback to race with a victim's callback can obtain a tinyauth session with the victim's identity. This grants unauthorized access to all resources the victim is permitted to access through tinyauth's ACL system. The probability of collision increases with concurrent OAuth traffic.

The PKCE verifier overwrite additionally causes a denial-of-service: concurrent OAuth logins for the same provider reliably fail.

Multiple concurrent operations access a shared resource without proper synchronization, producing unpredictable results depending on timing. Typical impact: TOCTOU exploits, data corruption, or privilege escalation.

CVE-2026-33544 has a CVSS score of 7.7 (High). The vector is network-reachable, low privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.0.1-0.20260401140714-fc1d4f2082a5); upgrading removes the vulnerable code path.

Kodem intelligence

Pass verifier and token through method parameters or return values instead of storing them on the singleton:

func (generic *GenericOAuthService) VerifyCode(code string, verifier string) (*oauth2.Token, error) {
    return generic.config.Exchange(generic.context, code, oauth2.VerifierOption(verifier))
}

func (generic *GenericOAuthService) Userinfo(token *oauth2.Token) (config.Claims, error) {
    client := generic.config.Client(generic.context, token)
    // ...
}

Store the PKCE verifier in the session/cookie associated with the OAuth state parameter, not on the service struct.

1. What is CVE-2026-33544? CVE-2026-33544 is a high-severity race condition vulnerability in github.com/steveiliop56/tinyauth (go), affecting versions < 1.0.1-0.20260401140714-fc1d4f2082a5. It is fixed in 1.0.1-0.20260401140714-fc1d4f2082a5. Multiple concurrent operations access a shared resource without proper synchronization, producing unpredictable results depending on timing.
2. How severe is CVE-2026-33544? CVE-2026-33544 has a CVSS score of 7.7 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of github.com/steveiliop56/tinyauth are affected by CVE-2026-33544? github.com/steveiliop56/tinyauth (go) versions < 1.0.1-0.20260401140714-fc1d4f2082a5 is affected.
4. Is there a fix for CVE-2026-33544? Yes. CVE-2026-33544 is fixed in 1.0.1-0.20260401140714-fc1d4f2082a5. Upgrade to this version or later.
5. Is CVE-2026-33544 exploitable, and should I be worried? Whether CVE-2026-33544 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-33544 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-33544? Upgrade github.com/steveiliop56/tinyauth to 1.0.1-0.20260401140714-fc1d4f2082a5 or later.