Summary
Gitea contains a server-side request forgery vulnerability in HTTP fetch operations used by migration and OAuth avatar workflows. An authenticated attacker may provide crafted URLs to reach internal services, cloud metadata endpoints, or local files, with retrieved content potentially persisted as migration release assets.
Affected context
The vulnerability can occur in Gitea deployments that use affected migration or OAuth avatar code paths to fetch attacker-influenced URLs. These operations rely on Go's default HTTP client behavior without a custom network dialer that restricts destinations, so requests may reach network locations that should not be accessible from the server.
Exploit preconditions
- Attack surface: HTTP fetch operations in repository migration and OAuth avatar workflows
- Required access: An authenticated Gitea account with access to a feature that accepts or processes attacker-controlled URLs
- Trigger point: Processing release asset download URLs, pull-request patch URLs, or OAuth avatar endpoints
- Why exploitation is possible: The fetch logic does not consistently enforce destination restrictions through a custom
DialContext, allowing server-side requests to attacker-selected internal or local targets
Why this happens
The underlying flaw is insufficient validation and network-level enforcement for server-side URL fetching. Using a default HTTP client without a restricted dialing policy allows application-controlled requests to resolve and connect to destinations such as private network services or cloud metadata endpoints. This behavior maps to CWE-918: Server-Side Request Forgery, because attacker-influenced URLs are fetched from the application's network context without adequate destination controls.
Potential impact
- Internal services may be probed or accessed from the Gitea server
- Cloud instance metadata and temporary credentials could be disclosed
- Local application files may be read where supported by the fetch path
- Database credentials, signing secrets, or other configuration data could be exposed
- Retrieved content may be persisted as migration release assets for later retrieval
- Internal network reconnaissance or follow-on compromise could occur
General mitigation guidance
Mitigation generally focuses on reducing trust in user-supplied URLs and enforcing outbound network boundaries.
Common defensive patterns include:
- Use an HTTP client with a restrictive dialer and explicit destination allowlist
- Reject loopback, link-local, private, multicast, and reserved address ranges after hostname resolution
- Restrict or disable unsupported URL schemes and avoid file-oriented fetch behavior
- Revalidate destinations across redirects and prevent DNS-rebinding bypasses
- Separate URL retrieval from sensitive service networks through egress controls
- Avoid persisting fetched content unless its origin and purpose have been validated
- Run the application with minimal network and filesystem privileges
How teams detect issues like this
Organizations can identify SSRF risks through:
- Static analysis rules for HTTP requests constructed from user-controlled URLs
- Code review checks for default clients used without restricted dialing or redirect policies
- Review of migration, avatar, webhook, import, and asset-fetching features
- Runtime monitoring for outbound connections to loopback, private, link-local, and metadata addresses
- Egress firewall policies and proxy logs that flag unexpected internal or cloud-control-plane access
- Automated security review tools that identify missing URL validation and network-boundary enforcement
