Gitea CVE-2026-25946

Exploitation requires that OpenID sign-in is enabled on the Gitea instance (the [openid] ENABLE_OPENID_SIGNIN setting), which the vendor patch changes to default false - so vulnerable deployments are those that have deliberately turned OpenID on. When enabled, no authentication or user interaction is needed (PR:N/UI:N): the attacker supplies an OpenID URL to the sign-in flow and Gitea performs discovery requests without validating the destination against loopback/private-network addresses. The primary limiting factors are: (1) OpenID sign-in must be active and unrestricted; and (2) in patched versions a default BLACKLISTED_URIS block list (localhost, loopback, private ranges, 169.254.0.0/16, fe80::/10) prevents the internal requests, so instances with the fix and default config are protected even with OpenID enabled.

This is a genuine but moderate-priority issue, not a top-tier emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N) and the description agree and are internally consistent: an unauthenticated remote attacker can trigger the flaw with low complexity by supplying a crafted OpenID URL, so there is no network/local-access contradiction to flag. However, several signals pull the real-world risk down. Impact is limited to C:L (I:N/A:N) - this is a server-side request forgery that exposes internal service behavior and enables interaction with otherwise-unreachable hosts, not code execution or data destruction, which matches CWE-918 and the SSVC 'Technical Impact: partial' rating. The SSVC framework reports Exploitation: poc (proof-of-concept, not active exploitation) and Automatable: yes (the discovery request can be scripted at scale). There is no CISA KEV listing and no EPSS score was provided in the input, so widespread active exploitation is NOT confirmed. The single most important mitigating factor is a precondition: the vulnerable code path only exists when OpenID sign-in is explicitly enabled, and the vendor patch changes the default of ENABLE_OPENID_SIGNIN to false, confirming this is not on by default. Net: a real, automatable, unauthenticated SSRF worth patching promptly on any Gitea instance that uses OpenID, but the limited confidentiality-only impact and the non-default configuration requirement keep it well below critical.

An attacker reaches the public Gitea OpenID sign-in endpoint and submits an OpenID identifier pointing at an internal address (e.g. http://127.0.0.1:/ or a private-LAN service), causing the Gitea server itself to issue a discovery HTTP request to that internal target. The attacker observes response differences or timing to map and probe internal services that are not directly routable from the internet. Proof-of-concept-level exploitation is indicated by the SSVC 'poc' status, and the attack requires no authentication (PR:N) and low complexity (AC:L).