When the [oauth2_client] UPDATE_AVATAR setting is enabled in Gitea, the server fetches the avatar URL provided by the OAuth2/OIDC provider's picture claim using Go's default HTTP client without applying any host or IP restrictions. This allows a low-privileged OAuth2/OIDC user who can influence their picture claim to cause the Gitea server to perform arbitrary outbound HTTP GET requests, including to loopback, private network, and link-local IP addresses. The vulnerable code path does not enforce the host restrictions that other outbound fetches in Gitea do. The SSRF is blind because the response content is not directly returned to the attacker, but impact can increase if internal services return valid image data within size limits, which may be stored as the user's avatar. This can enable internal service probing and limited response retrieval depending on network access controls and deployment environment.

A low-privileged OAuth2/OIDC user with control over their picture claim can cause the Gitea server to make arbitrary outbound HTTP GET requests to internal or private network addresses. This can lead to internal network reconnaissance and interaction with services not accessible from the public internet, such as cloud metadata services, localhost-only services, or internal admin panels. The SSRF is blind by default, limiting direct data exfiltration, but if internal endpoints return valid image data within the configured avatar size limit, the attacker may retrieve limited information by having that data stored as their avatar.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until a fix is available, consider disabling the [oauth2_client] UPDATE_AVATAR setting to prevent server-side fetching of user-controlled avatar URLs. Review and restrict OAuth2/OIDC provider configurations to limit attacker control over the picture claim. Monitor for updates from the Gitea project regarding an official fix and apply it promptly once released.