Gitea CVE-2026-104636

Requires an authenticated repository administrator to configure a push mirror, wiki remote check, or pull-request-head migration whose remote URL targets an endpoint explicitly permitted by the outbound host policy (ALLOWED_HOST_LIST / allowed domains) that then issues an HTTP redirect to an address the policy would otherwise deny. Exploitation is meaningfully LIMITED by: (1) repo-admin privilege to set remote URLs (contradicting the vector's PR:N); (2) a restrictive outbound host policy must actually be configured, otherwise there is no boundary to bypass; (3) the attacker must control or locate an allowed endpoint that redirects to the desired internal target; and (4) realized impact is bounded by which internal services are reachable from the server and what the Git client can do with them (the advisory states impact depends on policy and reachable services). Not exploitable where no egress allow-list is enforced or where a proxy handles egress restriction.

This is CWE-918 server-side request forgery in Gitea: initial remote URLs are validated against the outbound host policy, but subsequent raw Git operations follow HTTP redirects without revalidating the destination, letting a policy-allowed endpoint redirect Gitea's Git client to an internal address the policy would block. The official CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N = 7.5) marks it network-reachable and unauthenticated, but the description explicitly states the actor is 'a repository administrator' configuring push mirrors, wiki remote checks, or migrated-PR-head fetches - a clear CONFLICT: PR:N implies no auth, yet exploitation requires an authenticated repo-admin who can set a remote URL, so the real-world privilege bar is higher than the headline score suggests. Exploitation signals are weak: EPSS is 0.15% (3rd percentile), there is no CISA KEV listing and no public exploit identified at time of analysis, indicating no observed or likely widespread exploitation. The I:H/C:N impact rating is also debatable for an SSRF - reachability of internal services typically yields confidentiality exposure rather than pure integrity impact, and the advisory itself says impact 'depends on the configured policy and the internal services reachable,' so the fixed I:H is an upper-bound assumption. Net: a legitimate security boundary bypass worth patching, but a moderate priority (authenticated admin precondition, config-dependent impact, low EPSS, no exploitation evidence) rather than a drop-everything network-unauthenticated RCE that the 7.5/PR:N framing might imply.

A repository administrator (or an attacker who has compromised such an account) configures a push mirror or migration whose remote URL points at an endpoint permitted by ALLOWED_HOST_LIST but which returns an HTTP redirect to an internal-only address such as a cloud metadata service or an intranet admin panel. Because the raw Git operation follows the redirect without re-checking the outbound host policy, Gitea's server issues requests to that blocked internal destination. No public proof-of-concept is identified; the attack requires network access to the Gitea instance plus repo-admin rights, with complexity low once a redirecting allowed endpoint is available.