Gitea EUVD-2026-58126

Migration path: requires the attacker to possess or obtain an API token with migration permission on the target Gitea instance (admin or org-owner role), AND to operate or control a Gitea-compatible server that serves malicious release asset download URLs or PR patch URLs. The target Gitea instance must have external migration enabled (on by default). OAuth avatar path: requires an administrator to have configured a custom OAuth2 authentication source whose provider is attacker-controlled (e.g., a self-hosted OAuth server), allowing the provider to return an avatar URL pointing to an internal resource. The file:// local read vector is limited to the uri.Open() code path in the migration flow (release assets and PR patches) and reads files accessible to the OS user running the Gitea process. What limits exploitation: the primary barrier is that the migration attack requires admin or org-owner privileges on the target; the OAuth vector requires prior admin configuration of a custom OAuth2 source pointing to an attacker-controlled server. Default-configured Gitea instances with no custom OAuth2 sources and no admin account compromise are not immediately exploitable from an unauthenticated remote position.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N = 7.5) conflicts materially with the vulnerability description: the migration attack path explicitly requires migration permission (admin or org owner), and the OAuth vector requires an admin-configured custom OAuth2 source. A PR:N rating is therefore inconsistent with the stated prerequisites - security teams should treat the published CVSS score with caution and reassess assuming PR:H. Adjusted to PR:H, the base score drops to approximately 4.9. EPSS at 0.16% (6th percentile) corroborates that real-world exploitation is not currently widespread, which aligns with the non-trivial privilege barrier. However, the published PoC is detailed and operational, and the potential payoff - cloud IMDSv1 credentials granting lateral movement to cloud resources, or app.ini leaking the database password and JWT signing secret enabling complete account takeover - is disproportionately high relative to the effort for an insider or compromised admin account. KEV listing is absent, so confirmed active exploitation is not established. Overall: genuine priority for cloud-hosted Gitea instances where admin accounts could be compromised or where insider threat is a concern; lower priority for air-gapped or on-premises deployments without cloud metadata endpoints.

An attacker who holds admin or org-owner privileges on a target Gitea instance (or who socially engineers a legitimate admin) sets up a malicious Gitea server at a domain they control and creates a release with asset download URLs pointing to http://169.254.169.254/latest/meta-data/iam/security-credentials/role or file:///etc/gitea/app.ini. They trigger (or cause the admin to trigger) a repo migration via the API from the malicious server; Gitea's migration process fetches those URLs using unprotected http.Get() or uri.Open(), saves the response bodies as migrated release assets, and the attacker retrieves the cloud credentials or app.ini contents by downloading the migrated release asset from the now-accessible repository. A working PoC demonstrating this chain is published in the GitHub Security Advisory.