SSRF via HTTP Redirect in Repository Migration

Affected: Go: code.gitea.io/gitea

## 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 serv…

Ein entfernter, authentisierter Angreifer kann mehrere Schwachstellen in Gitea ausnutzen, um seine Privilegien zu erhöhen, Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren, vertrauliche Informationen offenzulegen oder einen Denial-of-Service-Zustand zu verursachen.