Authorizer CVSS 9.3 Flaw Enables OAuth Token Theft

RFC 6749, the OAuth 2.0 specification, is explicit on this point: authorization servers must compare the redirect_uri submitted with an authorization request against the exact values registered for that client, and reject anything that does not match. Authorizer, the open-source self-hosted authentication server, did not do this before version 2.2.1.

CVE-2026-54072 (CVSS 9.3, critical) is the result. The /authorize endpoint accepted any redirect_uri without checking it against a registered allowlist. An unauthenticated attacker with a valid authorization URL could substitute their own server as the redirect target, receiving the authorization code that the server would normally deliver only to the registered application.

What open redirect means in an OAuth context

The vulnerability class is well established. When an OAuth authorization server hands an authorization code to a redirect URI, that code is a short-lived credential that the receiving application exchanges for access tokens. If the redirect goes to the wrong server, the code goes with it, and so does the subsequent token exchange.

Getting there requires social engineering: the attacker needs a user to initiate an authorization flow via a crafted URL. No session or credential is required from the attacker’s side. The user’s existing session with the Authorizer instance does the work; the attacker only needs to supply the redirect destination and receive what the server sends.

The GitHub advisory sets the fix at version 2.2.1. The GHSA-h29v-hj44-q8cv page has the full details.

Who is exposed

Authorizer is a self-hosted alternative to managed identity providers. Teams running it chose that model specifically to keep authentication infrastructure on their own servers. That means affected instances are spread across individual organization deployments rather than concentrated at a single provider, and there is no central mechanism to track or coordinate patching.

If your organization runs Authorizer and has not updated to 2.2.1, the /authorize endpoint is currently processing redirect URIs without validating them.

Patch

Update to Authorizer 2.2.1 or later. Check the version tag in your deployment before and after. No partial mitigation substitutes for the upstream fix, though a reverse proxy or gateway that enforces redirect URI allowlisting independently provides some depth while the upgrade is in progress.

This is the kind of bug that sits quietly in self-hosted infrastructure, because nobody is scanning your instance for you. The spec requirement has been in RFC 6749 since 2012. Version 2.2.1 is available now.

Related: JSCeal Malware Bypasses Google Auth with Stolen Cookies and our Threat Intelligence coverage.