Summary
Gitea did not revalidate destinations after following HTTP redirects during certain Git operations, including push mirror updates, wiki remote checks, and migrated pull request head fetches. A repository administrator could use an allowed endpoint that redirects to a blocked address, potentially causing the server to contact internal services or other destinations permitted only by the configured outbound policy.
Gitea did not revalidate destinations after following HTTP redirects during certain Git operations, including push mirror updates, wiki remote checks, and migrated pull request head fetches. A repository administrator could use an allowed endpoint that redirects to a blocked address, potentially causing the server to contact internal services or other destinations permitted only by the configured outbound policy.
Affected context
The vulnerability occurs in Gitea workflows that perform raw Git network operations after validating a remote URL. It is relevant where repository administrators can configure or influence remote endpoints and where the Git client follows HTTP redirects without applying the same destination policy to the final address. The practical impact depends on the outbound network controls and services reachable from the Gitea host.
The vulnerability occurs in Gitea workflows that perform raw Git network operations after validating a remote URL. It is relevant where repository administrators can configure or influence remote endpoints and where the Git client follows HTTP redirects without applying the same destination policy to the final address. The practical impact depends on the outbound network controls and services reachable from the Gitea host.
Exploit preconditions
- Attack surface: Gitea Git operations involving push mirrors, wiki remotes, or migrated pull request heads
- Required access: Repository administrator privileges or equivalent ability to configure or influence a policy-allowed remote endpoint
- Trigger point: A Git request that follows an HTTP redirect to a different destination
- Why exploitation is possible: The initial URL is checked, but the redirected destination is not revalidated against the outbound host policy
- Attack surface: Gitea Git operations involving push mirrors, wiki remotes, or migrated pull request heads
- Required access: Repository administrator privileges or equivalent ability to configure or influence a policy-allowed remote endpoint
- Trigger point: A Git request that follows an HTTP redirect to a different destination
- Why exploitation is possible: The initial URL is checked, but the redirected destination is not revalidated against the outbound host policy
Why this happens
The underlying bug is inconsistent validation across a multi-step network request. Gitea validated the initial remote URL but trusted the HTTP client's redirected destination without applying the same allowlist or blocklist rules again. This behavior maps to CWE-918: Server-Side Request Forgery, because attacker-influenced input can cause the server to initiate requests to destinations that should not be reachable under the configured policy.
The underlying bug is inconsistent validation across a multi-step network request. Gitea validated the initial remote URL but trusted the HTTP client's redirected destination without applying the same allowlist or blocklist rules again. This behavior maps to CWE-918: Server-Side Request Forgery, because attacker-influenced input can cause the server to initiate requests to destinations that should not be reachable under the configured policy.
Potential impact
- Gitea may send requests to internal or otherwise restricted services
- Internal service metadata or responses could be exposed through application behavior or logs
- Network-level access controls could be bypassed for destinations reachable from the Gitea host
- Sensitive services may receive unintended Git or HTTP requests
- The impact could extend to connected systems depending on network placement and service authentication
- Gitea may send requests to internal or otherwise restricted services
- Internal service metadata or responses could be exposed through application behavior or logs
- Network-level access controls could be bypassed for destinations reachable from the Gitea host
- Sensitive services may receive unintended Git or HTTP requests
- The impact could extend to connected systems depending on network placement and service authentication
General mitigation guidance
Mitigation generally focuses on treating every redirect destination as untrusted and enforcing outbound request policy throughout the complete request lifecycle.
Common defensive patterns include:
- Revalidating each redirect target against an explicit destination allowlist
- Disabling automatic redirects for security-sensitive Git operations where practical
- Restricting outbound connectivity from Gitea to only required services and networks
- Separating Gitea from sensitive internal management and metadata endpoints
- Requiring explicit approval for repository remote and mirror configuration
- Running the service with least-privilege network and identity permissions
- Applying consistent URL parsing, DNS, IP-range, and redirect handling rules across all network clients
Mitigation generally focuses on treating every redirect destination as untrusted and enforcing outbound request policy throughout the complete request lifecycle.
Common defensive patterns include:
- Revalidating each redirect target against an explicit destination allowlist
- Disabling automatic redirects for security-sensitive Git operations where practical
- Restricting outbound connectivity from Gitea to only required services and networks
- Separating Gitea from sensitive internal management and metadata endpoints
- Requiring explicit approval for repository remote and mirror configuration
- Running the service with least-privilege network and identity permissions
- Applying consistent URL parsing, DNS, IP-range, and redirect handling rules across all network clients
How teams detect issues like this
Organizations can look for SSRF risks through:
- Static analysis of HTTP and Git client code for redirect-following behavior without destination revalidation
- Code review checks for URL validation performed only before a network request begins
- Tests covering redirects between public, private, loopback, link-local, and otherwise restricted address ranges
- Network monitoring for unexpected connections from Gitea to internal services or unusual external destinations
- Audit logging of repository remote, mirror, and migration configuration changes
- Egress firewall and service-mesh policies that alert on or deny unauthorized destinations
Automated security review tools may help identify incomplete redirect validation and unsafe outbound request patterns.
Organizations can look for SSRF risks through:
- Static analysis of HTTP and Git client code for redirect-following behavior without destination revalidation
- Code review checks for URL validation performed only before a network request begins
- Tests covering redirects between public, private, loopback, link-local, and otherwise restricted address ranges
- Network monitoring for unexpected connections from Gitea to internal services or unusual external destinations
- Audit logging of repository remote, mirror, and migration configuration changes
- Egress firewall and service-mesh policies that alert on or deny unauthorized destinations
Automated security review tools may help identify incomplete redirect validation and unsafe outbound request patterns.
Sources
| Source | Link |
|---|---|
| blog. | blog.gitea.com/ |
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
