GHSA-xxhq-69mf-w8cr Gogs has an Open Redirect via redirect_to

• Go gogs.io/gogs: < 0.14.3 → fixed in 0.14.3

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 ``` 2. 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