CVE-2026-58314

The 'two findings' framing in CVE-2026-58314 is analytically significant — it suggests either a pattern of recurring SSRF mishandling across distinct code paths, or that a single audit surface revealed systemic input validation failures, and either interpretation carries different implications for how you assess Gitea's secure development lifecycle. Treat this as two entry points into the same architectural weakness until proven otherwise: when SSRF findings cluster in the same release, they typically share a common ancestor in a shared URL-fetching utility rather than representing independent failures. That means patching one feature while leaving the other unreviewed leaves your deployment exposed. SSRF in self-hosted git platforms carries asymmetric risk compared to traditional web applications. Gitea servers routinely make outbound requests during ordinary operations — repository mirrors, webhooks, avatar services, package registries, and OAuth flows all require the application to fetch external resources. This legitimate functionality creates a large attack surface where the line between intended fetch and forgery is easy to cross incorrectly. The EPSS score (0.00295) measures opportunistic, automated exploitation probability, which is the wrong model for self-hosted infrastructure. Your attacker isn't running a mass scan — they already have visibility into your deployment's internal topology. They know whether your instance can reach AWS metadata endpoints at 169.254.169.254, whether it runs with a service account tied to Kubernetes APIs, or whether your private package registry shares a subnet. The question isn't whether this CVE will be automated-scanned; it's whether your instance can reach sensitive internal resources, and whether that attack path was accounted for in your network segmentation. Prioritize these actions: First, assume both findings involve different Gitea features until the advisory clarifies otherwise, and audit your entire outbound request subsystem — webhooks, avatars, mirror syncing, and OAuth — not just the two disclosed vectors. Second, verify your network segmentation explicitly restricts Gitea's outbound access: block metadata endpoints, restrict which internal services the Gitea server can reach, and assume the application account has more network reach than you intend. Third, check whether Gitea's documentation addresses what network paths your instance can reach during ordinary operations — most hardening guides focus on attacker-controlled inputs, but mirror syncing may reach internal resources without any user-supplied URL at all. Fourth, treat this disclosure as a signal that Go URL-parsing antipatterns (redirect following after initial validation, hostname re-check after DNS resolution, scheme stripping in parsed URLs) likely persist in untested code paths — expect a third finding and plan accordingly.

Reviewed through automated stages and approved by a human before publication.