GHSA-rqhx-647v-wx32: Gitea: SSRF via HTTP Redirect in Repository Migration
Summary
Gitea 1.25.4 validates the initial URL provided to the repository migration endpoint (POST /api/v1/repos/migrate) and correctly blocks requests to internal addresses like 127.0.0.1 or RFC1918 ranges. However, if the initial URL points to an attacker-controlled server that responds with an HTTP 302 redirect to an internal address, Gitea follows the redirect without performing a second validation. This allows a low-privilege user to reach internal services through Gitea as a proxy.
Affected Version
Gitea 1.25.4 (latest stable at time of writing), default configuration.
Prerequisites
1. A regular Gitea user account (no admin privileges required)
2. An attacker-controlled server reachable from the internet that serves HTTP 302 redirects
Reproduction
Environment
| Role | Location | Network |
|------------------|----------------------------------------------------------------|------------------------------------------|
| Attacker | Any machine with internet access | External network (VLAN A) |
| Gitea Server | Windows 11 VM, Gitea 1.25.4, default config, SQLite | Internal network (VLAN B) |
| Internal service | Same VM, bound to 127.0.0.1:18082 | Localhost only |
| Redirect server | Attacker-controlled public server, port 18080 | Internet |
The attacker can reach Gitea on port 3000 but cannot reach port 18082 on the VM. This was verified by attempting a direct connection, which was refused.
Step 1: Create an attacker account on Gitea
Register a normal user account on the Gitea instance (or use any existing non-admin account). Then generate an API token under Settings > Applications with the repo: write scope. The migration endpoint requires this because it creates a new repository. This token is referenced as <USER_TOKEN> in the steps below.
Step 2: Set up an internal service on the Gitea host
On the Gitea VM, create a bare Git repository that simulates an internal service:
mkdir C:\internal-repo
cd C:\internal-repo
git init
echo CONFIDENTIAL_DATA_20
Details
Original advisory: https://github.com/advisories/GHSA-rqhx-647v-wx32
Exploitation outlook
EPSS (FIRST.org) estimates each CVE’s probability of exploitation in the next 30 days — here is the CSIRTS.com read on those numbers.
- Low exploitation riskCVE-2026-584180.24% 30-day exploitation probability — currently an unlikely target, but scores change as exploit code circulates. Riskier than 16% of all scored CVEs.
Referenced CVEs
| CVE | CSIRTS overview | External |
|---|---|---|
| CVE-2026-58418 | coverage & exploitation status | NVD · CVE.org |
Same CVEs, other sources
How other CERTs, PSIRTs and databases cover the vulnerabilities in this advisory.
More from GitHub Security Advisories
- mediumGHSA-jr6p-8pjj-mfx6: Capsule has an incomplete fix of CVE-2026-22872: TenantResource RawItems and Generators s…2026-07-31
- mediumGHSA-68cj-mvg9-rgm2: Capsule: CapsuleConfiguration NodeMetadata regex fields lack webhook validation, allowing…2026-07-31
- mediumGHSA-ff84-5f28-78qj: re2: Out-of-bounds heap read in `exec`/`test`/`match` via attacker-influenced `lastIndex`…2026-07-31
- mediumGHSA-6hxr-mr5r-9836: re2: Global `String.prototype.match` with an empty-matchable pattern never advances → inf…2026-07-31
- mediumGHSA-x83g-979r-f5fh: Sylius Mollie Plugin has unauthenticated IDOR that leaks order token and customer PII2026-07-31