GHSA-9RC6-8CJV-RCVX
Vulnerability from github – Published: 2026-06-26 23:05 – Updated: 2026-06-26 23:051. Description
The getRedirectURL function in oauth2.go:22-29 constructs the OAuth2 callback URL by concatenating the request's Host header with a fixed path, with zero validation of the Host header:
func getRedirectURL(c *gin.Context) string {
scheme := "http://"
referer := c.Request.Referer()
if forwardedProto := c.Request.Header.Get("X-Forwarded-Proto"); forwardedProto == "https" || strings.HasPrefix(referer, "https://") {
scheme = "https://"
}
return scheme + c.Request.Host + "/api/v1/oauth2/callback"
}
File: cmd/dashboard/controller/oauth2.go:22-29
This function is called from oauth2redirect() at line 53:
func oauth2redirect(c *gin.Context) (*model.Oauth2LoginResponse, error) {
// ...
redirectURL := getRedirectURL(c)
o2conf := o2confRaw.Setup(redirectURL)
// ...
url := o2conf.AuthCodeURL(state, oauth2.AccessTypeOnline)
return &model.Oauth2LoginResponse{Redirect: url}, nil
}
The redirectURL is passed into o2confRaw.Setup(redirectURL) which configures the OAuth2 Config.RedirectURL field (oauth2config.go:22-33). This RedirectURL is sent to the OAuth2 provider (e.g., GitHub, Google, Microsoft) as the callback endpoint. The OAuth2 provider will redirect the user's browser — along with the authorization code — to this URL after the user authenticates.
The security issue is that c.Request.Host is directly user-controllable via the HTTP Host header. An attacker who can control which Host header reaches the oauth2redirect handler can:
- Set
Host: evil.com getRedirectURLreturnshttps://evil.com/api/v1/oauth2/callback- The OAuth2 provider redirects the victim's auth code to
evil.com - The attacker's server at
evil.comcaptures the auth code - The attacker exchanges the code for an access token, binding the victim's OAuth identity to the attacker's dashboard account
The scheme detection (lines 24-27) uses X-Forwarded-Proto and the Referer header, both of which are also user-controllable in certain configurations, so the attacker can force https:// scheme in the redirect URL.
The oauth2callback handler at line 129 later uses state.RedirectURL (which is stored in singleton.Cache at line 65) when calling exchangeOpenId at line 152. The cached redirectURL was set during the initial oauth2redirect call, tying the attack flow together.
2. PoC
A conceptual attack (no Docker needed):
Scenario: OAuth2 provider has loose redirect URI validation
(e.g., allows wildcard subdomain matching)
1. Attacker crafts a URL to the dashboard's OAuth2 login endpoint
with a modified Host header:
GET /api/v1/oauth2/github HTTP/1.1
Host: attacker-controlled.com
X-Forwarded-Proto: https
2. The dashboard responds with a redirect to:
https://github.com/login/oauth/authorize?client_id=...&redirect_uri=https://attacker-controlled.com/api/v1/oauth2/callback&state=...
3. Victim clicks the attacker's link → authenticates with GitHub
→ GitHub redirects to https://attacker-controlled.com/api/v1/oauth2/callback?code=AUTH_CODE&state=...
4. Attacker captures the AUTH_CODE from their server logs
5. Attacker exchanges the code at the real dashboard's
/api/v1/oauth2/callback endpoint (using the real Host header
this time), binding the victim's OAuth identity to their
dashboard account
Prerequisites for full exploit:
- The victim must click the attacker's crafted link
- The OAuth2 provider must accept the attacker's domain as a valid redirect URI (some providers accept https://*/* or allow wildcards; others are strict)
3. Impact
- Account takeover: an attacker who intercepts the OAuth2 authorization code can bind the victim's OAuth identity (GitHub, Google, GitLab, etc.) to their own dashboard account, gaining the victim's access level and permissions
- Privilege escalation: if the victim is an admin, the attacker gains full administrative control over the Nezha deployment — access to all servers, credentials, and configuration
- Persistence: once bound, the attacker retains access even if the victim resets their password (unless they also unbind the OAuth2 identity)
The attack complexity is higher than typical Host header injection scenarios because it requires:
1. The Host header to reach the dashboard's handler unmodified (bypassing reverse proxy normalization)
2. The OAuth2 provider to have loose redirect URL validation
3. User interaction (the victim must authenticate)
However, the code-level vulnerability is unambiguous: the application trusts attacker-controlled input (Host header) for a security-critical URL that participates in the OAuth2 authorization code flow.
4. Remediation
-
Validate the Host header against a configured allowlist of known dashboard hostnames:
go func getRedirectURL(c *gin.Context) string { host := c.Request.Host if !singleton.Conf.IsAllowedHost(host) { host = singleton.Conf.DashboardBaseURL // fallback } // ... } -
Pin the redirect URL to the configured dashboard URL from
singleton.Confinstead of deriving it from the request Host header:go func getRedirectURL(c *gin.Context) string { return singleton.Conf.DashboardBaseURL + "/api/v1/oauth2/callback" } -
Remove Host header-based URL construction entirely — the OAuth2 redirect URL should be deterministic based on server configuration, not dynamic per-request
-
Add Host header validation middleware for all OAuth2-related endpoints as defense-in-depth
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/nezhahq/nezha"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "2.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53523"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-26T23:05:19Z",
"nvd_published_at": "2026-06-12T22:16:52Z",
"severity": "MODERATE"
},
"details": "## 1. Description\n\nThe `getRedirectURL` function in `oauth2.go:22-29` constructs the OAuth2 callback URL by concatenating the request\u0027s `Host` header with a fixed path, with **zero validation** of the Host header:\n\n```go\nfunc getRedirectURL(c *gin.Context) string {\n scheme := \"http://\"\n referer := c.Request.Referer()\n if forwardedProto := c.Request.Header.Get(\"X-Forwarded-Proto\"); forwardedProto == \"https\" || strings.HasPrefix(referer, \"https://\") {\n scheme = \"https://\"\n }\n return scheme + c.Request.Host + \"/api/v1/oauth2/callback\"\n}\n```\n\n**File:** `cmd/dashboard/controller/oauth2.go:22-29`\n\nThis function is called from `oauth2redirect()` at line 53:\n```go\nfunc oauth2redirect(c *gin.Context) (*model.Oauth2LoginResponse, error) {\n // ...\n redirectURL := getRedirectURL(c)\n o2conf := o2confRaw.Setup(redirectURL)\n // ...\n url := o2conf.AuthCodeURL(state, oauth2.AccessTypeOnline)\n return \u0026model.Oauth2LoginResponse{Redirect: url}, nil\n}\n```\n\nThe `redirectURL` is passed into `o2confRaw.Setup(redirectURL)` which configures the OAuth2 `Config.RedirectURL` field (`oauth2config.go:22-33`). This `RedirectURL` is sent to the OAuth2 provider (e.g., GitHub, Google, Microsoft) as the callback endpoint. The OAuth2 provider will redirect the user\u0027s browser \u2014 along with the authorization code \u2014 to this URL after the user authenticates.\n\nThe security issue is that `c.Request.Host` is directly user-controllable via the HTTP `Host` header. An attacker who can control which Host header reaches the oauth2redirect handler can:\n\n1. Set `Host: evil.com`\n2. `getRedirectURL` returns `https://evil.com/api/v1/oauth2/callback`\n3. The OAuth2 provider redirects the victim\u0027s auth code to `evil.com`\n4. The attacker\u0027s server at `evil.com` captures the auth code\n5. The attacker exchanges the code for an access token, binding the victim\u0027s OAuth identity to the attacker\u0027s dashboard account\n\nThe scheme detection (lines 24-27) uses `X-Forwarded-Proto` and the `Referer` header, both of which are also user-controllable in certain configurations, so the attacker can force `https://` scheme in the redirect URL.\n\nThe `oauth2callback` handler at line 129 later uses `state.RedirectURL` (which is stored in `singleton.Cache` at line 65) when calling `exchangeOpenId` at line 152. The cached `redirectURL` was set during the initial `oauth2redirect` call, tying the attack flow together.\n\n## 2. PoC\n\nA conceptual attack (no Docker needed):\n\n```\nScenario: OAuth2 provider has loose redirect URI validation\n (e.g., allows wildcard subdomain matching)\n\n1. Attacker crafts a URL to the dashboard\u0027s OAuth2 login endpoint\n with a modified Host header:\n\n GET /api/v1/oauth2/github HTTP/1.1\n Host: attacker-controlled.com\n X-Forwarded-Proto: https\n\n2. The dashboard responds with a redirect to:\n https://github.com/login/oauth/authorize?client_id=...\u0026redirect_uri=https://attacker-controlled.com/api/v1/oauth2/callback\u0026state=...\n\n3. Victim clicks the attacker\u0027s link \u2192 authenticates with GitHub\n \u2192 GitHub redirects to https://attacker-controlled.com/api/v1/oauth2/callback?code=AUTH_CODE\u0026state=...\n\n4. Attacker captures the AUTH_CODE from their server logs\n\n5. Attacker exchanges the code at the real dashboard\u0027s\n /api/v1/oauth2/callback endpoint (using the real Host header\n this time), binding the victim\u0027s OAuth identity to their\n dashboard account\n```\n\n**Prerequisites for full exploit:**\n- The victim must click the attacker\u0027s crafted link\n- The OAuth2 provider must accept the attacker\u0027s domain as a valid redirect URI (some providers accept `https://*/*` or allow wildcards; others are strict)\n\n## 3. Impact\n\n- **Account takeover**: an attacker who intercepts the OAuth2 authorization code can bind the victim\u0027s OAuth identity (GitHub, Google, GitLab, etc.) to their own dashboard account, gaining the victim\u0027s access level and permissions\n- **Privilege escalation**: if the victim is an admin, the attacker gains full administrative control over the Nezha deployment \u2014 access to all servers, credentials, and configuration\n- **Persistence**: once bound, the attacker retains access even if the victim resets their password (unless they also unbind the OAuth2 identity)\n\nThe attack complexity is higher than typical Host header injection scenarios because it requires:\n1. The `Host` header to reach the dashboard\u0027s handler unmodified (bypassing reverse proxy normalization)\n2. The OAuth2 provider to have loose redirect URL validation\n3. User interaction (the victim must authenticate)\n\nHowever, the code-level vulnerability is unambiguous: the application trusts attacker-controlled input (`Host` header) for a security-critical URL that participates in the OAuth2 authorization code flow.\n\n## 4. Remediation\n\n1. **Validate the Host header** against a configured allowlist of known dashboard hostnames:\n ```go\n func getRedirectURL(c *gin.Context) string {\n host := c.Request.Host\n if !singleton.Conf.IsAllowedHost(host) {\n host = singleton.Conf.DashboardBaseURL // fallback\n }\n // ...\n }\n ```\n\n2. **Pin the redirect URL** to the configured dashboard URL from `singleton.Conf` instead of deriving it from the request Host header:\n ```go\n func getRedirectURL(c *gin.Context) string {\n return singleton.Conf.DashboardBaseURL + \"/api/v1/oauth2/callback\"\n }\n ```\n\n3. **Remove Host header-based URL construction** entirely \u2014 the OAuth2 redirect URL should be deterministic based on server configuration, not dynamic per-request\n\n4. **Add Host header validation middleware** for all OAuth2-related endpoints as defense-in-depth",
"id": "GHSA-9rc6-8cjv-rcvx",
"modified": "2026-06-26T23:05:19Z",
"published": "2026-06-26T23:05:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nezhahq/nezha/security/advisories/GHSA-9rc6-8cjv-rcvx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53523"
},
{
"type": "PACKAGE",
"url": "https://github.com/nezhahq/nezha"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Nezha Monitoring: OAuth2 Redirect URL \u2014 Host Header Injection"
}
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.