Description

Authorizer is an open-source, self-hostable authentication and authorization server. Prior to version 2.2.1, the `/authorize` endpoint accepts any `redirect_uri` without validating it against `AllowedOrigins`. When `response_type=token` or `response_type=id_token`, the server appends `access_token`, `id_token`, and `refresh_token` as query parameters and issues a 302 redirect to the attacker-supplied URL. An unauthenticated attacker can obtain the required `client_id` from the public `/graphql?query={meta{client_id}}` endpoint. A partial fix was applied in v2.0.1 to other handlers (`oauth_login`, `verify_email`, `magic_link_login`, `forgot_password`, `invite_members`, `oauth_callback`) but `/authorize` was not included. Version 2.2.1 contains a more complete fix.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.3",
  "pubDate": "2026-09-11T19:17:42.663Z",
  "pubdate": "2026-09-11T19:17:42.663Z",
  "executiveSummary": "Authorizer versions prior to 2.2.1 contain an open redirect vulnerability within the /authorize endpoint that facilitates OAuth token exfiltration.\nThe vulnerability occurs due to the server's failure to perform allow-list validation against the provided redirect_uri, allowing an attacker to force the server to redirect legitimate authentication tokens to an arbitrary, attacker-controlled domain.\nThe impact is significant, as an unauthenticated attacker can capture access_token, id_token, and refresh_token values associated with a victim's session.\nThis flaw effectively bypasses OAuth security boundaries, potentially leading to full account takeover.\nExploitation requires minimal technical effort, as the necessary client_id is publicly discoverable via the /graphql endpoint.\nSystems running affected versions are at high risk of unauthorized session hijacking and data exposure.\nOrganizations must upgrade to version 2.2.1 or later to implement proper origin validation and secure the OAuth flow against redirection-based token theft.",
  "technicalDetails": "The root cause of this vulnerability lies in an improper input validation flaw within the /authorize endpoint of the Authorizer authentication server. Specifically, the implementation fails to verify the user-supplied redirect_uri against the server's configured AllowedOrigins list.\nWhen a request is made to the /authorize endpoint with a response_type of token or id_token, the server logic generates authentication tokens and appends them as URL query parameters to the redirect destination. Because the validation logic is missing, the server performs a 302 HTTP redirect to the attacker-supplied URI, effectively leaking sensitive credentials through the 'Location' header.\nThe attack flow begins with the attacker retrieving the client_id, which is publicly accessible via the /graphql?query={meta{client_id}} endpoint. Once the client_id is obtained, the attacker crafts a malicious link targeting the /authorize endpoint. This URL includes an arbitrary attacker-controlled domain as the redirect_uri parameter.\nWhen an authenticated user (or a victim coerced into clicking the link) visits the URL, the Authorizer server processes the request, appends the victim's access_token, id_token, and refresh_token to the attacker's URL, and triggers a browser redirect. The victim's browser inadvertently sends these tokens to the attacker's server, which logs the incoming request parameters.\nThe vulnerable component is the /authorize request handler. While previous patches (v2.0.1) addressed similar vulnerabilities in other handlers such as oauth_login, verify_email, magic_link_login, forgot_password, invite_members, and oauth_callback, the /authorize path remained exposed until version 2.2.1. This oversight highlights a lack of consistent security middleware application across all OAuth-related entry points.\nThis vulnerability is particularly critical because it requires no prior authentication from the attacker. The network exposure is absolute for any self-hosted instance reachable over the internet. Post-exploitation, the attacker possesses valid identity and session tokens, enabling them to impersonate the victim, access protected resources, and potentially escalate privileges within the scope of the hijacked identity."
}