CVE-2026-82402 in Gogs
Summary
by MITRE • 10/14/2026
Gogs is an open source self-hosted Git service. Prior to 0.15.0+dev, an unauthenticated attacker can provide a backslash-containing target to the /redirect endpoint, and similar post-action redirect flows are also affected. internal/urlx/urlx.go IsSameSite validates a normalized form of the target while cmd/gogs/internal/web/web.go getRedirect and other callers use the original value in the Location response. This backslash normalization mismatch lets browsers interpret the Location value as a scheme-relative external URL, allowing links on a trusted Gogs domain to redirect victims to attacker-controlled content for phishing. This vulnerability is fixed in 0.15.0+dev.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability identified within Gogs prior to version 0.15.0+dev represents a critical open redirect flaw rooted in inconsistent URL normalization logic during the handling of HTTP redirects. As an open source self-hosted Git service, Gogs relies heavily on user trust and secure navigation flows. The specific technical defect resides in the discrepancy between how internal validation functions process target URLs versus how they are ultimately applied in server responses. Specifically, the function IsSameSite located in the internal/urlx/urlx.go module validates a normalized form of the provided target URL to ensure it remains within expected boundaries or same-site contexts. However, the actual redirect logic executed by getRedirect and other callers in cmd/gogs/internal/web/web.go utilizes the original, unnormalized value when constructing the Location header for the HTTP response. This architectural mismatch creates a bypass mechanism where input validation passes because the normalized version appears safe, but the browser receives the raw, potentially malicious string.
The operational impact of this flaw is significant due to its potential for facilitating phishing attacks and session hijacking attempts through social engineering. An unauthenticated attacker can craft a request containing a backslash character within the target parameter sent to the /redirect endpoint or similar post-action redirect flows. In many web browsers, particularly those adhering to specific parsing standards like RFC 3986, a forward slash followed by two other slashes denotes an absolute protocol-relative URL. However, when a backslash is introduced in certain positions before such sequences, some browser engines may interpret the path differently or fail to properly escape it, effectively treating the remainder of the string as part of the host component rather than the path. This allows the attacker to construct URLs that appear to originate from the trusted Gogs domain but actually redirect the victim's browser to an external, attacker-controlled server.
This type of vulnerability is classically categorized under CWE-601, which defines URL Redirection to Untrusted Site (Open Redirect). The exploitation technique aligns with MITRE ATT&CK techniques related to Phishing and Social Engineering, specifically where trusted domains are leveraged to increase the credibility of malicious links. By exploiting this inconsistency, an attacker can create a link that looks legitimate in the browser's address bar or social media previews, thereby tricking users into entering credentials on a fake login page hosted by the attacker. Since Gogs is often used for sensitive code repositories and internal development workflows, compromising user trust through such redirects could lead to broader security incidents including credential theft and unauthorized access to private repositories.
The resolution of this issue in version 0.15.0+dev involves correcting the normalization logic so that both validation and execution use a consistent representation of the URL target. Security practitioners managing Gogs instances should ensure they are running patched versions or applying manual mitigations if upgrading is not immediately feasible. Mitigation strategies include implementing strict allow-listing for redirect targets rather than relying solely on blacklist-based checks, ensuring that all outbound redirects undergo rigorous normalization before being processed by web server modules, and configuring Content Security Policy headers to restrict navigation destinations where possible. Regular audits of URL handling logic across application components are essential to prevent similar discrepancies between validation layers and execution contexts in future updates or custom integrations.