GHSA-x3f4-v83f-7wp2 Authorizer: Password reset token theft and full auth token redirect via unvalidated redirect_uri
Hi,I found that 6 endpoints in Authorizer accept a user-controlled `redirect_uri` and append sensitive tokens to it without validating the URL against `AllowedOrigins`. The OAuth `/app` handler validates redirect_uri at `http_handlers/app.go:46`, but the GraphQL mutations and verify_email handler skip validation entirely. An attacker can steal password reset tokens, magic link tokens, and full auth sessions (access_token + id_token + refresh_token) by pointing redirect_uri to their server. Verified against HEAD (commit 73679fa).Affected Endpoints**ForgotPassword** (`internal/graphql/forgot_password.go:76-77`) - password reset tokens**MagicLinkLogin** (`internal/graphql/magic_link_login.go:150-151`) - magic link auth tokens**Signup** (`internal/graphql/signup.go:211-212`) - email verification tokens**InviteMembers** (`internal/graphql/invite_members.go:90-91`) - invitation tokens**OAuthLoginHandler** (`internal/http_handlers/oauth_login.go:18-20`) - OAuth redirect stored in state**VerifyEmailHandler** (`internal/http_handlers/verify_email.go:27,178`) - full auth tokens (access + id + refresh)Root CauseBecause these 6 endpoints completely lack the `validators.IsValidOrigin()` check, this vulnerability bypasses secure configurations. Even if a production administrator strictly configures `AllowedOrigins` to `["https://my-secure-app.com"]`, an attacker can still steal tokens by passing `https://attacker.com` to these specific GraphQL mutations. The validation only exists in the `/app` OAuth handler, not in any of the GraphQL mutations.In `forgot_password.go:76-77`, the user-supplied `redirect_uri` is accepted without validation:The reset token is appended to this URL at `internal/utils/common.go:77`:Compare with the OAuth flow at `internal/http_handlers/app.go:46` which validates correctly:This validation is missing from all 6 endpoints listed above.Most Severe Path: Full Token Theft via verify_emailAfter a user clicks the verification link, `verify_email.go:178` generates full auth tokens and redirects to the (unvalidated) URL:The redirect_uri is stored in the JWT claim from the original request (attacker-controlled). The attacker receives the victim's access_token, id_token, and refresh_token directly.Because tokens are appended as URL query parameters, they are also automatically leaked to the attacker's server access logs, the victim's browser history, and any third-party analytics scripts on the attacker's page via the `Referer` header.PoCThe victim receives a legitimate password reset email with the link `https://attacker.com/steal?token=<reset_token>`. Clicking the link sends the reset token to the attacker.ImpactAccount takeover via stolen password reset tokensFull session theft via stolen access_token + id_token + refresh_tokenPasswordless account compromise via stolen magic link tokensNo authentication required to trigger (the GraphQL mutations are public)Victim only needs to click the email link from their trusted Authorizer instanceAdditional NoteThe default `AllowedOrigins` at `cmd/root.go:39` is `["*"]`, so even the OAuth endpoint's validation is a no-op by default. Recommend changing the default to require explicit configuration.Koda Reef
CVSS v4.0 score: 8.6