Gogs has an Open Redirect via redirect_to

Summary

An open redirect vulnerability exists in Gogs where attacker-controlled redirect_to parameters can bypass validation, allowing redirection to arbitrary external sites.

Details

All redirects in Gogs that are validated via the IsSameSite function are vulnerable:

func IsSameSite(url string) bool {
    return len(url) >= 2 && url[0] == '/' && url[1] != '/' && url[1] != '\\'
}

The function only inspects the first two characters of the URL string. This check fails to account for directory traversal sequences followed by backslashes. For example:

/a/../\example.com

The IsSameSite function checks the input supplied to the redirect_to query parameter value /a/../\example.com and considers it valid.

Because web browsers normalize backslashes \ to forward slashes /, the normalized URL becomes //example.com.

The normalized URL becomes:

//example.com

Resulting in a cross-origin redirect.

This affects all endpoints using the redirect_to query parameter, including login and other post-action flows.

PoC

1. An attacker can provide a user with a link to login to Gogs with a redirect_to query parameter that redirects a user to a site the attacker wants them to visit:

http://192.168.236.132:3000/user/login?redirect_to=/a/../\example.com

<img width="1339" height="536" alt="image" src="https://github.com/user-attachments/assets/3c2a13b8-f0b7-42c2-a223-6f0ebf083589" />

<br> <br>

2. After the user successfully logs in, they would be redirected to the site an attacker wants them to visit:

<img width="1066" height="463" alt="image" src="https://github.com/user-attachments/assets/1726a3d9-6705-43cc-bdd2-90aad105d021" />

<img width="1097" height="396" alt="image" src="https://github.com/user-attachments/assets/376052f5-0e00-4d14-a548-fa75a6269530" />

Impact

• Phishing: Attackers can use trusted domain links to redirect victims to credential-harvesting pages
• OAuth/SSO Token Theft: In authentication flows, authorization codes or tokens may leak via redirect
• Referer Leakage: Sensitive URL parameters may be exposed to attacker domains via the Referer header
• Cache Poisoning: In deployments with shared caches, malicious redirects may be cached and served to other users