Summary
Gitea's push mirror feature checked a remote address against migration allow and block lists only when the mirror was created, rather than during each synchronization. If the name later resolved to an internal or blocked address, an administrator-level repository user could cause repository contents to be pushed to that destination.
Gitea's push mirror feature checked a remote address against migration allow and block lists only when the mirror was created, rather than during each synchronization. If the name later resolved to an internal or blocked address, an administrator-level repository user could cause repository contents to be pushed to that destination.
Affected context
The issue occurs in Gitea deployments that use push mirrors and validate mirror destinations only during initial configuration. It becomes risky when DNS or name resolution can change after validation, allowing a previously permitted name to resolve to an internal, restricted, or otherwise blocked Git service during a later synchronization.
The issue occurs in Gitea deployments that use push mirrors and validate mirror destinations only during initial configuration. It becomes risky when DNS or name resolution can change after validation, allowing a previously permitted name to resolve to an internal, restricted, or otherwise blocked Git service during a later synchronization.
Exploit preconditions
- Attack surface: Gitea push mirror synchronization - Required access: Administrator access to a repository, including a
repository created by that user
- Trigger point: A subsequent push mirror synchronization - Relevant condition: The configured hostname resolves differently after
creation or can resolve to an internal or blocked destination
- Why exploitation is possible: Destination validation is performed at
configuration time, while the stored address is reused without equivalent
validation during synchronization
- Attack surface: Gitea push mirror synchronization - Required access: Administrator access to a repository, including a
repository created by that user
- Trigger point: A subsequent push mirror synchronization - Relevant condition: The configured hostname resolves differently after
creation or can resolve to an internal or blocked destination
- Why exploitation is possible: Destination validation is performed at
configuration time, while the stored address is reused without equivalent
validation during synchronization
Why this happens
The underlying bug is a time-of-check to time-of-use error, mapped primarily to CWE-367. Gitea validated a mirror destination at one point in time but trusted the stored hostname during later network operations, even though name resolution could produce a different address. This behavior also creates a server-side request forgery condition, represented by CWE-918, because server-side synchronization may connect to destinations that were not approved when the connection is made.
The underlying bug is a time-of-check to time-of-use error, mapped primarily to CWE-367. Gitea validated a mirror destination at one point in time but trusted the stored hostname during later network operations, even though name resolution could produce a different address. This behavior also creates a server-side request forgery condition, represented by CWE-918, because server-side synchronization may connect to destinations that were not approved when the connection is made.
Potential impact
- An attacker may cause repository contents to be sent to an internal Git service.
- The synchronization could reach network locations excluded by migration policies.
- Internal repository data may be exposed or overwritten.
- A force-push may alter the history or contents of a destination repository.
- The activity could support further discovery of internal services.
- An attacker may cause repository contents to be sent to an internal Git service.
- The synchronization could reach network locations excluded by migration policies.
- Internal repository data may be exposed or overwritten.
- A force-push may alter the history or contents of a destination repository.
- The activity could support further discovery of internal services.
General mitigation guidance
Mitigation generally focuses on validating the effective destination at the time of every outbound connection, rather than relying solely on configuration-time checks. Secure-by-default designs can resolve names, reject private, loopback, link-local, and otherwise restricted addresses, and apply allowlists immediately before connection establishment. DNS changes and redirects should not bypass policy enforcement. Outbound network access should be limited through egress controls, mirror permissions should follow least privilege, and force-push behavior should be restricted where repository integrity requires it.
Mitigation generally focuses on validating the effective destination at the time of every outbound connection, rather than relying solely on configuration-time checks. Secure-by-default designs can resolve names, reject private, loopback, link-local, and otherwise restricted addresses, and apply allowlists immediately before connection establishment. DNS changes and redirects should not bypass policy enforcement. Outbound network access should be limited through egress controls, mirror permissions should follow least privilege, and force-push behavior should be restricted where repository integrity requires it.
How teams detect issues like this
Detection can include static analysis for destination validation that occurs only during object creation, while later network calls reuse stored hostnames or addresses. Code review should examine DNS resolution, redirect handling, IP-range validation, and whether checks occur immediately before outbound connections. Runtime monitoring can correlate push mirror jobs with DNS changes, connections to private address ranges, unexpected internal Git endpoints, and unusual force-push activity. Network policy enforcement and automated security review tools can provide additional coverage.
Detection can include static analysis for destination validation that occurs only during object creation, while later network calls reuse stored hostnames or addresses. Code review should examine DNS resolution, redirect handling, IP-range validation, and whether checks occur immediately before outbound connections. Runtime monitoring can correlate push mirror jobs with DNS changes, connections to private address ranges, unexpected internal Git endpoints, and unusual force-push activity. Network policy enforcement and automated security review tools can provide additional coverage.
Sources
| Source | Link |
|---|---|
| blog. | blog.gitea.com/ |
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
