Listen to this Post
How CVE-2026-53523 Works
Nezha Monitoring is a self-hostable, lightweight servers and websites monitoring and O&M tool. From version 1.0.0 to before version 2.2.0, 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.
The vulnerable function is defined as follows:
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"
}
This function is called from `oauth2redirect()` at line 53, which passes the `redirectURL` into `o2confRaw.Setup(redirectURL)` to configure the OAuth2 `Config.RedirectURL` field. 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`
– `getRedirectURL` returns https://evil.com/api/v1/oauth2/callback`https://` scheme in the redirect URL. The `oauth2callback` handler later uses `state.RedirectURL` (stored in
- The OAuth2 provider redirects the victim's auth code to `evil.com`
- The attacker's server at `evil.com` captures 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 uses `X-Forwarded-Proto` and the `Referer` header, both of which are also user-controllable in certain configurations, allowing the attacker to force thesingleton.Cache) when calling exchangeOpenId, tying the attack flow together.
The vulnerability is classified as CWE-601: URL Redirection to Untrusted Site (‘Open Redirect’). It has a CVSS 3.1 base score of 6.8 (MEDIUM) with the vector: AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N.
DailyCVE Form
Platform: Nezha Monitoring
Version: 1.0.0 to 2.1.x
Vulnerability: OAuth2 Host Header Injection
Severity: MEDIUM (CVSS 6.8)
date: 2026-06-12
Prediction: Patch expected 2026-06-26
What Undercode Say
Check current Nezha version ./nezha --version Verify if vulnerable (versions < 2.2.0) curl -I http://your-nezha-dashboard.com/api/v1/oauth2/github \ -H "Host: attacker-controlled.com" \ -H "X-Forwarded-Proto: https" Expected vulnerable response: redirect to attacker-controlled.com
PoC: Craft OAuth2 login request with malicious Host header GET /api/v1/oauth2/github HTTP/1.1 Host: attacker-controlled.com X-Forwarded-Proto: https Dashboard responds with redirect to: https://github.com/login/oauth/authorize?client_id=...&redirect_uri=https://attacker-controlled.com/api/v1/oauth2/callback&state=...
After victim authenticates, attacker captures auth code from logs tail -f /var/log/nginx/access.log | grep "code=" Exchange code at real dashboard curl -X POST https://real-dashboard.com/api/v1/oauth2/callback \ -d "code=AUTH_CODE&state=..."
Exploit
Prerequisites:
- Victim must click the attacker’s crafted link
- OAuth2 provider must accept the attacker’s domain as a valid redirect URI (some providers accept `https:///` or allow wildcards)
- The `Host` header must reach the dashboard’s handler unmodified (bypassing reverse proxy normalization)
Attack Flow:
- Attacker crafts a URL to the dashboard’s OAuth2 login endpoint with a modified `Host` header
- The dashboard responds with a redirect to the OAuth2 provider with `redirect_uri` pointing to the attacker’s domain
- Victim clicks the attacker’s link → authenticates with the OAuth2 provider → provider redirects to the attacker’s domain with the authorization code
- Attacker captures the authorization code from server logs
- Attacker exchanges the code at the real dashboard’s `/api/v1/oauth2/callback` endpoint, binding the victim’s OAuth identity to the attacker’s dashboard account
Technical Details:
– Vulnerability exists in `cmd/dashboard/controller/oauth2.go`
– Cached `redirectURL` stored in `singleton.Cache` ties the attack flow together
– Attack technique: MITRE ATT&CK T1204.001 (User Execution)
Protection
Immediate Remediation:
– Upgrade to version 2.2.0 or later where the vulnerability has been patched
Code-Level Fixes:
1. Validate the `Host` header against a configured allowlist of known dashboard hostnames:
func getRedirectURL(c gin.Context) string {
host := c.Request.Host
if !singleton.Conf.IsAllowedHost(host) {
host = singleton.Conf.DashboardBaseURL // fallback
}
// ...
}
2. Pin the redirect URL to the configured dashboard URL from `singleton.Conf` instead of deriving it from the request `Host` header:
func getRedirectURL(c gin.Context) string {
return singleton.Conf.DashboardBaseURL + "/api/v1/oauth2/callback"
}
3. Remove `Host` header-based URL construction entirely — the OAuth2 redirect URL should be deterministic based on server configuration, not dynamic per-request
4. Add `Host` header validation middleware for all OAuth2-related endpoints as defense-in-depth
Temporary Mitigations:
– Configure reverse proxy to normalize or reject malformed `Host` headers
– Use strict OAuth2 provider redirect URI validation (avoid wildcard patterns like `https:///`)
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)
- Confidentiality and Integrity Impact: CVSS indicates HIGH impact on both confidentiality and integrity
The attack complexity is higher than typical `Host` header injection scenarios because it requires the `Host` header to reach the dashboard’s handler unmodified (bypassing reverse proxy normalization), the OAuth2 provider to have loose redirect URL validation, and user interaction (the victim must authenticate). However, the code-level vulnerability is unambiguous: the application trusts attacker-controlled input (Hostheader) for a security-critical URL that participates in the OAuth2 authorization code flow.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
