GHSA-h2x6-g7q6-344v: Gitea: Repository migration SSRF via multi-answer DNS allow-list bypass
Summary
Gitea's repository migration URL validation can be bypassed when a migration hostname resolves to multiple IP addresses. The validation logic accepts the destination if any resolved IP is allowed, even if another resolved IP is loopback, private, or otherwise blocked. The later git clone operation resolves the hostname again outside of that validation decision, so it can connect to the internal address.
An authenticated low-privilege user who can create repository migrations can use an attacker-controlled DNS name to make Gitea connect to internal-only Git services and import their contents into a repository controlled by the attacker.
Details
The issue is in services/migrations/migrate.go, in the migration allow/block-list check.
Current logic computes whether any resolved IP is allowed:
var ipAllowed bool
var ipBlocked bool
for _, addr := range addrList {
ipAllowed = ipAllowed || allowList.MatchIPAddr(addr)
ipBlocked = ipBlocked || blockList.MatchIPAddr(addr)
}
Then, when an allow-list is active, the host is accepted if the hostname matches or ipAllowed is true:
if !allowList.IsEmpty() {
if !allowList.MatchHostName(hostName) && !ipAllowed {
return &git.ErrInvalidCloneAddr{Host: hostName, IsPermissionDenied: true}
}
}
This means a hostname resolving to both:
- an allowed public IP, e.g. 1.2.3.4
- a blocked internal IP, e.g. 127.0.0.1
passes validation because the public IP sets ipAllowed = true.
The actual repository import is later performed by git clone --mirror via MigrateRepositoryGitData / gitrepo.CloneExternalRepo. That git subprocess performs its own DNS resolution and is not tied to the specific IP set that was validated earlier. If the hostname resolves, rotates, or is re-bound to the internal address at clone time, Gitea can connect to a destination the migration filter would reject if supplied directly.
The direct internal URL is correctly blocked, but the multi-answer hostname is accepted.
PoC
I verified the vulnerable predicate l
Details
Original advisory: https://github.com/advisories/GHSA-h2x6-g7q6-344v
Referenced CVEs
| CVE | CSIRTS overview | External |
|---|---|---|
| CVE-2026-58442 | coverage & exploitation status | NVD · CVE.org |
Same CVEs, other sources
How other CERTs, PSIRTs and databases cover the vulnerabilities in this advisory.
- high[NEW] [high] Gitea: Multiple vulnerabilitiescert-bund
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