GHSA-9Q5M-JFC4-WC92
Vulnerability from github – Published: 2026-04-01 19:52 – Updated: 2026-04-06 17:18Summary
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):
- User A and User B both click "Login with GitHub" on the same tinyauth instance
- Both are redirected to GitHub, authorize, and GitHub redirects both back with authorization codes
- 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
Impact
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.
Suggested Fix
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.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/steveiliop56/tinyauth"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.1-0.20260401140714-fc1d4f2082a5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33544"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-01T19:52:04Z",
"nvd_published_at": "2026-04-02T15:16:39Z",
"severity": "HIGH"
},
"details": "### Summary\n\nAll 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\u0027s identity.\n\n### Details\n\nThe [`OAuthBrokerService.GetService()`](https://github.com/steveiliop56/tinyauth/blob/592b7ded24959013f8af63ab9930254c752c8c8e/internal/service/oauth_broker_service.go#L70-L72) returns a single shared instance per provider for every request. The OAuth flow stores intermediate state as struct fields on this singleton:\n\n**Token storage** \u2014 [`generic_oauth_service.go` line 96](https://github.com/steveiliop56/tinyauth/blob/592b7ded24959013f8af63ab9930254c752c8c8e/internal/service/generic_oauth_service.go#L96):\n```go\ngeneric.token = token // Shared mutable field on singleton\n```\n\n**Verifier storage** \u2014 [`generic_oauth_service.go` line 81](https://github.com/steveiliop56/tinyauth/blob/592b7ded24959013f8af63ab9930254c752c8c8e/internal/service/generic_oauth_service.go#L81):\n```go\ngeneric.verifier = verifier // Shared mutable field on singleton\n```\n\nIn the callback handler [`oauth_controller.go` lines 136\u2013143](https://github.com/steveiliop56/tinyauth/blob/592b7ded24959013f8af63ab9930254c752c8c8e/internal/controller/oauth_controller.go#L136-L143), the code calls:\n```go\nerr = service.VerifyCode(code) // line 136 \u2014 stores token on singleton\n// ... race window ...\nuser, err := controller.broker.GetUser(req.Provider) // line 143 \u2014 reads token from singleton\n```\n\nBetween these two calls, a concurrent request\u0027s `VerifyCode()` can overwrite the `token` field, causing `GetUser()` \u2192 `Userinfo()` to fetch the **wrong user\u0027s** identity claims.\n\nThe same pattern exists in all three implementations:\n- [`github_oauth_service.go` lines 34\u201339, 77, 86\u201399](https://github.com/steveiliop56/tinyauth/blob/592b7ded24959013f8af63ab9930254c752c8c8e/internal/service/github_oauth_service.go#L34-L39)\n- [`google_oauth_service.go` lines 22\u201327, 65, 73\u201387](https://github.com/steveiliop56/tinyauth/blob/592b7ded24959013f8af63ab9930254c752c8c8e/internal/service/google_oauth_service.go#L22-L27)\n\n### PoC\n\n**Race scenario** (two concurrent OAuth callbacks):\n\n1. User A and User B both click \"Login with GitHub\" on the same tinyauth instance\n2. Both are redirected to GitHub, authorize, and GitHub redirects both back with authorization codes\n3. Both callbacks arrive at tinyauth nearly simultaneously:\n\n```\nTimeline:\n t0: Request A \u2192 service.VerifyCode(codeA) \u2192 singleton.token = tokenA\n t1: Request B \u2192 service.VerifyCode(codeB) \u2192 singleton.token = tokenB (overwrites tokenA)\n t2: Request A \u2192 broker.GetUser(\"github\") \u2192 Userinfo() reads singleton.token = tokenB\n t3: Request A receives User B\u0027s identity (email, name, groups)\n```\n\nUser A now has a tinyauth session with User B\u0027s email, gaining access to all resources User B is authorized for via tinyauth\u0027s ACL.\n\n**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.\n\n**Static verification**: Run Go\u0027s race detector on a test that calls `VerifyCode` and `Userinfo` concurrently on the same service instance \u2014 the `-race` flag will flag data races on the `token` and `verifier` fields.\n\n**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).\n\n**Test environment**: tinyauth v5.0.4, commit `592b7ded`, Go race detector + source code analysis\n\n### Impact\n\nAn attacker who times their OAuth callback to race with a victim\u0027s callback can obtain a tinyauth session with the victim\u0027s identity. This grants unauthorized access to all resources the victim is permitted to access through tinyauth\u0027s ACL system. The probability of collision increases with concurrent OAuth traffic.\n\nThe PKCE verifier overwrite additionally causes a denial-of-service: concurrent OAuth logins for the same provider reliably fail.\n\n### Suggested Fix\n\nPass verifier and token through method parameters or return values instead of storing them on the singleton:\n\n```go\nfunc (generic *GenericOAuthService) VerifyCode(code string, verifier string) (*oauth2.Token, error) {\n return generic.config.Exchange(generic.context, code, oauth2.VerifierOption(verifier))\n}\n\nfunc (generic *GenericOAuthService) Userinfo(token *oauth2.Token) (config.Claims, error) {\n client := generic.config.Client(generic.context, token)\n // ...\n}\n```\n\nStore the PKCE verifier in the session/cookie associated with the OAuth `state` parameter, not on the service struct.",
"id": "GHSA-9q5m-jfc4-wc92",
"modified": "2026-04-06T17:18:24Z",
"published": "2026-04-01T19:52:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/steveiliop56/tinyauth/security/advisories/GHSA-9q5m-jfc4-wc92"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33544"
},
{
"type": "WEB",
"url": "https://github.com/steveiliop56/tinyauth/commit/f26c2171610d5c2dfbba2edb6ccd39490e349803"
},
{
"type": "PACKAGE",
"url": "https://github.com/steveiliop56/tinyauth"
},
{
"type": "WEB",
"url": "https://github.com/steveiliop56/tinyauth/releases/tag/v5.0.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Tinyauth has OAuth account confusion via shared mutable state on singleton service instances"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.