CVE-2026-54072: Authorizer Authentication Bypass Vulnerability

CVE-2026-54072 Overview

CVE-2026-54072 is an open redirect vulnerability [CWE-601] in Authorizer, an open-source self-hostable authentication and authorization server. The /authorize endpoint accepts any redirect_uri value without validating it against the configured AllowedOrigins list. When a client requests response_type=token or response_type=id_token, the server appends access_token, id_token, and refresh_token as query parameters on a 302 redirect to the attacker-controlled URL. Versions prior to 2.2.1 are affected. Version 2.2.1 contains the complete fix.

Critical Impact

An unauthenticated attacker can hijack authenticated user sessions by capturing access, ID, and refresh tokens delivered to a malicious redirect target.

Affected Products

• Authorizer versions prior to 2.2.1
• Deployments exposing the /authorize endpoint with response_type=token or response_type=id_token
• Instances relying on the partial v2.0.1 fix that did not cover /authorize

Discovery Timeline

• 2026-09-11 - CVE-2026-54072 published to NVD
• 2026-09-15 - Last updated in NVD database

Technical Details for CVE-2026-54072

Vulnerability Analysis

Authorizer's /authorize endpoint implements the OAuth 2.0 authorization request but omits validation of the redirect_uri parameter against the tenant's AllowedOrigins configuration. When the caller specifies response_type=token or response_type=id_token, the implicit flow returns tokens directly through the redirect. The server issues a 302 response with access_token, id_token, and refresh_token appended as query parameters to the attacker-supplied URL.

An attacker only needs a valid client_id to craft the malicious request. The public GraphQL endpoint /graphql?query={meta{client_id}} returns this identifier without authentication. A victim clicking a crafted link authenticates to the legitimate Authorizer instance, then has their tokens redirected to attacker infrastructure. The tokens permit full impersonation of the victim across any resource server that trusts the Authorizer tenant.

Root Cause

The root cause is missing allow-list enforcement on the redirect_uri parameter in the /authorize handler. A partial fix in v2.0.1 introduced origin validation in the oauth_login, verify_email, magic_link_login, forgot_password, invite_members, and oauth_callback handlers. The /authorize handler was not updated in that patch, leaving the implicit-grant redirect path unprotected until v2.2.1.

Attack Vector

Exploitation is remote and unauthenticated for the initial request preparation, but requires user interaction because the victim must complete authentication at the legitimate Authorizer instance. The attacker retrieves client_id from the unauthenticated GraphQL metadata endpoint, then delivers a crafted /authorize URL containing response_type=token and a redirect_uri pointing to attacker-controlled infrastructure. Upon successful authentication, the browser follows the 302 redirect and delivers the tokens to the attacker.

See the GitHub Security Advisory GHSA-h29v-hj44-q8cv for full technical details.

Detection Methods for CVE-2026-54072

Indicators of Compromise

• Requests to /authorize containing redirect_uri values that do not match any entry in the configured AllowedOrigins list.
• Unauthenticated GraphQL queries to /graphql requesting the meta{client_id} field from unusual source addresses.
• 302 responses from Authorizer whose Location header carries access_token, id_token, or refresh_token query parameters bound for external hosts.

Detection Strategies

• Parse Authorizer access logs and alert on /authorize requests where the redirect_uri host is not on the sanctioned allow list.
• Correlate paired events: an unauthenticated client_id disclosure via /graphql followed by /authorize traffic from the same source within a short window.
• Inspect outbound proxy logs for referrer chains that carry OAuth token fragments to third-party domains.

Monitoring Recommendations

• Forward Authorizer application and reverse-proxy logs to a centralized analytics pipeline for URL-parameter inspection.
• Track the version of every Authorizer deployment and flag any instance below 2.2.1.
• Monitor for anomalous token usage such as refresh-token replay from IP addresses that do not match the original authentication source.

How to Mitigate CVE-2026-54072

Immediate Actions Required

• Upgrade all Authorizer instances to version 2.2.1 or later without delay.
• Rotate signing keys and invalidate outstanding refresh tokens issued by vulnerable instances.
• Audit recent /authorize traffic for suspicious redirect_uri values and revoke sessions associated with matching users.

Patch Information

Version 2.2.1 introduces complete redirect_uri validation against AllowedOrigins in the /authorize handler, closing the gap left by the partial v2.0.1 fix. Details are published in the Authorizer GitHub Security Advisory.

Workarounds

• If immediate patching is not possible, block the /authorize endpoint at the reverse proxy for requests containing response_type=token or response_type=id_token.
• Restrict access to the /graphql endpoint so unauthenticated callers cannot retrieve client_id values.
• Enforce strict redirect_uri allow-listing at an upstream web application firewall by comparing the parameter against a hard-coded list of trusted origins.

# Example reverse-proxy rule to block implicit-flow requests until patched
# nginx configuration snippet
location /authorize {
    if ($arg_response_type ~* "^(token|id_token)$") {
        return 403;
    }
    proxy_pass http://authorizer_upstream;
}