Summary
Gitea's repository migration flow validates a destination hostname against network allow and block lists before starting a Git clone, but the Git subprocess resolves and connects independently. If an attacker can initiate a migration and control the destination's DNS, they may redirect the connection after validation to a blocked internal address.
Gitea's repository migration flow validates a destination hostname against network allow and block lists before starting a Git clone, but the Git subprocess resolves and connects independently. If an attacker can initiate a migration and control the destination's DNS, they may redirect the connection after validation to a blocked internal address.
Affected context
The issue can arise in deployments that:
- Allow users or integrations to start repository migrations
- Validate migration destinations before invoking Git
- Permit the Git subprocess to perform its own hostname resolution
- Rely on hostname-based network allow and block lists without enforcing the same policy at connection time
Risk depends on the permissions available to migration initiators and the network reachability of the process running Git.
The issue can arise in deployments that:
- Allow users or integrations to start repository migrations
- Validate migration destinations before invoking Git
- Permit the Git subprocess to perform its own hostname resolution
- Rely on hostname-based network allow and block lists without enforcing the same policy at connection time
Risk depends on the permissions available to migration initiators and the network reachability of the process running Git.
Exploit preconditions
- Attack surface: Repository migration and Git clone functionality
- Required access: Permission to initiate a repository migration
- Attacker capability: Control over the destination hostname's DNS responses
- Trigger point: Git connects to the migration destination after preliminary validation
- Why exploitation is possible: The validation component and Git subprocess resolve the hostname independently, creating a time-of-check-to-time-of-use gap that can allow a later connection to a restricted address
- Attack surface: Repository migration and Git clone functionality
- Required access: Permission to initiate a repository migration
- Attacker capability: Control over the destination hostname's DNS responses
- Trigger point: Git connects to the migration destination after preliminary validation
- Why exploitation is possible: The validation component and Git subprocess resolve the hostname independently, creating a time-of-check-to-time-of-use gap that can allow a later connection to a restricted address
Why this happens
The vulnerability is caused by applying network policy checks to one connection path while allowing a separate subprocess to resolve and connect to the destination independently.
This creates a DNS-based time-of-check-to-time-of-use condition: the address considered safe during validation may differ from the address used by Git. The behavior maps to CWE-918: Server-Side Request Forgery, because attacker-influenced destination handling can cause the server to make requests to unintended internal or restricted network locations.
The vulnerability is caused by applying network policy checks to one connection path while allowing a separate subprocess to resolve and connect to the destination independently.
This creates a DNS-based time-of-check-to-time-of-use condition: the address considered safe during validation may differ from the address used by Git. The behavior maps to CWE-918: Server-Side Request Forgery, because attacker-influenced destination handling can cause the server to make requests to unintended internal or restricted network locations.
Potential impact
- The application may connect to internal services that were intended to be blocked.
- An attacker could potentially access metadata endpoints or administrative interfaces reachable from the migration worker.
- Internal service information could be disclosed through migration errors, responses, or side effects.
- Network segmentation controls may be weakened for the process performing the Git operation.
- The application may connect to internal services that were intended to be blocked.
- An attacker could potentially access metadata endpoints or administrative interfaces reachable from the migration worker.
- Internal service information could be disclosed through migration errors, responses, or side effects.
- Network segmentation controls may be weakened for the process performing the Git operation.
General mitigation guidance
Mitigation generally focuses on enforcing destination policy at the actual connection boundary rather than only during preliminary hostname validation.
Common defensive patterns include:
- Resolve and validate destinations using a trusted, controlled networking layer.
- Ensure the Git operation uses the same validated address and policy context as the initial check.
- Revalidate connections after redirects, redirects-equivalent transitions, and DNS changes where applicable.
- Prefer explicit destination allowlists and reduce reliance on mutable hostname resolution.
- Block private, loopback, link-local, and other restricted address ranges at egress controls.
- Run migration workers with minimal network reachability and least-privilege permissions.
Mitigation generally focuses on enforcing destination policy at the actual connection boundary rather than only during preliminary hostname validation.
Common defensive patterns include:
- Resolve and validate destinations using a trusted, controlled networking layer.
- Ensure the Git operation uses the same validated address and policy context as the initial check.
- Revalidate connections after redirects, redirects-equivalent transitions, and DNS changes where applicable.
- Prefer explicit destination allowlists and reduce reliance on mutable hostname resolution.
- Block private, loopback, link-local, and other restricted address ranges at egress controls.
- Run migration workers with minimal network reachability and least-privilege permissions.
How teams detect issues like this
Organizations can look for SSRF and validation-bypass risks through:
- Static analysis rules identifying hostname validation followed by independent subprocess or library connections.
- Code review checks for DNS resolution performed separately by validators and network clients.
- Tests that exercise DNS changes between validation and connection without relying on fixed destination assumptions.
- Egress policy monitoring for migration workers connecting to private, link-local, loopback, or management network ranges.
- Runtime logging that correlates requested hostnames, resolved addresses, and actual connection targets.
Automated security review tools may help identify mismatched validation and connection paths, but network-level telemetry remains important for confirmation.
Organizations can look for SSRF and validation-bypass risks through:
- Static analysis rules identifying hostname validation followed by independent subprocess or library connections.
- Code review checks for DNS resolution performed separately by validators and network clients.
- Tests that exercise DNS changes between validation and connection without relying on fixed destination assumptions.
- Egress policy monitoring for migration workers connecting to private, link-local, loopback, or management network ranges.
- Runtime logging that correlates requested hostnames, resolved addresses, and actual connection targets.
Automated security review tools may help identify mismatched validation and connection paths, but network-level telemetry remains important for confirmation.
Sources
| Source | Link |
|---|---|
| blog. | blog.gitea.com/ |
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
