Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-52805

CVE-2026-52805: Gogs Git Service SSRF Vulnerability

CVE-2026-52805 is a Server-Side Request Forgery flaw in Gogs that allows authenticated attackers to bypass hostname validation and access internal endpoints. This article covers technical details, affected versions, and patches.

Published:

CVE-2026-52805 Overview

CVE-2026-52805 is a Server-Side Request Forgery (SSRF) vulnerability in Gogs, an open source self-hosted Git service. The flaw affects all versions prior to 0.14.3 and resides in the repository migration functionality. The application validates only the initially submitted URL hostname, but git clone --mirror follows HTTP redirects. An authenticated user can submit a public URL that redirects to a blocked internal endpoint such as 127.0.0.1, causing the server to import the contents of internal repositories into an attacker-controlled repository. The issue is tracked under [CWE-918] and is fixed in Gogs 0.14.3.

Critical Impact

Authenticated attackers can exfiltrate internal repository contents and reach blocked internal endpoints by exploiting redirect-following behavior in git clone operations.

Affected Products

  • Gogs versions prior to 0.14.3
  • Self-hosted Gogs Git service instances with repository migration enabled
  • Gogs deployments allowing authenticated user repository migrations

Discovery Timeline

  • 2026-06-24 - CVE-2026-52805 published to NVD
  • 2026-06-25 - Last updated in NVD database

Technical Details for CVE-2026-52805

Vulnerability Analysis

The vulnerability stems from incomplete URL validation in the repository migration workflow. Gogs validates only the hostname provided in the initial migration request against its internal blocklist. After validation, the application invokes git clone --mirror to fetch the remote repository. Git, by default, follows HTTP redirects without re-applying the application's hostname restrictions.

An authenticated attacker can host a public URL that responds with an HTTP redirect to an internal endpoint such as 127.0.0.1, link-local addresses, or internal service hostnames. Gogs accepts the initial request because the public hostname passes validation. The underlying git process then follows the redirect and clones content from the internal target, importing it into a repository owned by the attacker.

Root Cause

The root cause is a Time-of-Check Time-of-Use (TOCTOU) style mismatch: validation occurs on the user-supplied URL, but the actual network request is performed by an external process (git) that does not honor the application's URL policy. The patch introduces a new netx helper and replaces the prior git.IsURLAccessible call with isMirrorURLAccessible, which enforces SSRF-safe URL handling throughout the redirect chain.

Attack Vector

Exploitation requires an authenticated account with permission to create repository migrations. The attacker controls a public web server that issues an HTTP 3xx redirect pointing to an internal resource reachable by the Gogs host. User interaction is required only in the sense that the migration must be initiated; no victim user is involved. The exposed scope extends beyond the Gogs process because internal services responding to git protocol requests can leak repository data.

go
// Patch excerpt: internal/database/mirror.go
 	"github.com/gogs/git-module"
 
 	"gogs.io/gogs/internal/conf"
+	"gogs.io/gogs/internal/netx"
 	"gogs.io/gogs/internal/process"
 	"gogs.io/gogs/internal/sync"
 )

// Patch excerpt: internal/database/repo.go
 	remote = strings.TrimSuffix(remote, ".git")
 	for _, suffix := range commonWikiURLSuffixes {
 		wikiURL := remote + suffix
-		if git.IsURLAccessible(time.Minute, wikiURL) {
+		if isMirrorURLAccessible(time.Minute, wikiURL) {
 			return wikiURL
 		}
 	}
// Source: https://github.com/gogs/gogs/commit/b9a0093e9cd1b2b3c7f42f9feca396dc772c4f1b

Detection Methods for CVE-2026-52805

Indicators of Compromise

  • Repository migration requests submitted by authenticated users referencing external URLs that resolve via HTTP 3xx redirects to internal addresses.
  • Outbound HTTP requests from the Gogs host to public URLs immediately followed by git connections to loopback or RFC1918 addresses.
  • New repositories containing unexpected content matching internal services, configuration files, or non-public Git repositories.

Detection Strategies

  • Inspect Gogs application logs for migration attempts with remote URLs that returned redirect responses prior to clone execution.
  • Monitor egress traffic from Gogs servers for git protocol connections destined for internal IP ranges or 127.0.0.1.
  • Audit repository creation events for repositories created via migration whose content does not match the declared remote source.

Monitoring Recommendations

  • Enable network flow logging on the Gogs host to detect anomalous loopback and internal git fetch activity.
  • Alert on creation of repositories where the migration source URL host differs from the final fetched host after redirect resolution.
  • Track and review accounts that submit multiple migration requests pointing to externally hosted redirect endpoints.

How to Mitigate CVE-2026-52805

Immediate Actions Required

  • Upgrade Gogs to version 0.14.3 or later, which contains the SSRF fix referenced in GitHub Pull Request #8324.
  • Restrict repository migration permissions to trusted users until the upgrade is applied.
  • Review existing repositories created via migration since deployment for unexpected internal content.

Patch Information

The fix is included in Gogs v0.14.3. The patch, available in commit b9a0093, introduces an internal/netx package and replaces git.IsURLAccessible with a redirect-aware isMirrorURLAccessible helper. Additional details are documented in the GitHub Security Advisory GHSA-g2f5-gjr4-qjvm.

Workarounds

  • Place the Gogs server behind an egress proxy that blocks outbound connections to loopback, link-local, and internal IP ranges.
  • Disable repository migration functionality for non-administrative accounts via Gogs configuration until patching is complete.
  • Configure host firewall rules to prevent the Gogs process from initiating connections to internal services not required for normal operation.
bash
# Configuration example: restrict egress from Gogs host using iptables
iptables -A OUTPUT -m owner --uid-owner gogs -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner gogs -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner gogs -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner gogs -d 192.168.0.0/16 -j REJECT
iptables -A OUTPUT -m owner --uid-owner gogs -d 169.254.0.0/16 -j REJECT

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.