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: ``go 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 ``

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

### 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