CVE-2026-78231: 
Gitea vulnerability analysis and mitigation

CVE-2026-78231 is an unauthenticated blind Server-Side Request Forgery (SSRF) vulnerability in Gitea affecting all versions up to and including 1.26.4. When OpenID sign-in is enabled, an unauthenticated attacker can manipulate the OpenID verification flow to cause the Gitea server to send outbound HTTP POST requests to attacker-controlled URLs, enabling interaction with internal network services. The vulnerability was published on September 23, 2026, and patched in version 1.27.0. It carries a CVSS v3.1 base score of 5.3 (Moderate) (GitHub Advisory).

The root cause is improper trust of caller-supplied OpenID assertion parameters without sufficient validation of the destination endpoint (CWE-918). The vulnerable route is /user/login/openid, which is gated only by the openIDSignInEnabled configuration flag and does not require an authenticated session. When an unauthenticated attacker sends a crafted GET request to this endpoint with a malicious openid.op_endpoint parameter, the upstream github.com/yohcop/openid-go library issues a server-side HTTP POST request to the attacker-specified URL using http.DefaultClient — with no apparent request timeout, introducing an additional availability risk. The attacker controls both the destination URL and much of the form-encoded POST body via supplied OpenID query parameters (GitHub Advisory).

Because the response is not returned to the attacker, the SSRF is blind; however, it can still be used to trigger state-changing POST requests against internal services unreachable from the public internet, such as loopback services, internal admin panels, CI/CD endpoints, private-network APIs, and cloud metadata endpoints (e.g., 169.254.169.254). The primary confidentiality impact is low (internal network probing), integrity impact is limited to side effects on services accepting unauthenticated POST requests, and availability may be degraded if the Gitea server is directed to make requests to slow or non-responsive targets due to the lack of a timeout. The actual severity is highly environment-dependent and may be significantly higher in deployments where Gitea can reach sensitive unauthenticated internal services (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the time of disclosure. The EPSS score is 0.0 and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires only that OpenID sign-in ([openid] ENABLE_OPENID_SIGNIN = true) be enabled on the target instance, with no authentication or user interaction needed, making the attack surface relatively broad for self-hosted Gitea deployments that use this feature (GitHub Advisory).

1. Reconnaissance: Identify Gitea instances (e.g., via Shodan, Censys, or direct browsing) running version 1.26.4 or earlier. Confirm that OpenID sign-in is enabled by checking whether /user/login/openid returns a valid response rather than a 404 or disabled-feature error.
2. Craft malicious request: Prepare a GET request to /user/login/openid with attacker-controlled OpenID parameters, setting openid.op_endpoint to the target internal URL (e.g., http://169.254.169.254/latest/meta-data/ or http://internal-admin-panel/api/action) and populating other OpenID query parameters to control the POST body.
3. Trigger SSRF: Send the crafted GET request to the Gitea server. The github.com/yohcop/openid-go library will issue a server-side HTTP POST to the attacker-specified endpoint using http.DefaultClient.
4. Interact with internal services: Repeat with different target URLs to probe internal network topology, trigger state-changing actions on services accepting unauthenticated POST requests, or attempt to retrieve cloud instance metadata. Note that responses are not returned to the attacker (blind SSRF), so out-of-band techniques (e.g., DNS callbacks, timing analysis) may be needed to confirm reachability (GitHub Advisory).

• Network: Unusual outbound HTTP POST requests originating from the Gitea server process to internal IP ranges (RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback (127.0.0.1), or link-local addresses (169.254.0.0/16); outbound requests to unexpected external hosts from the Gitea process.
• Logs: Gitea access logs showing repeated unauthenticated GET requests to /user/login/openid with unusual or external openid.op_endpoint parameter values; HTTP client errors or timeouts logged by the openid-go library.
• Process: The Gitea server process initiating outbound TCP connections to ports 80/443 on internal hosts not normally contacted by the application.
• Application Logs: Errors or unexpected responses in Gitea logs related to OpenID verification failures against non-standard provider endpoints (GitHub Advisory).

Upgrade Gitea to version 1.27.0 or later, which contains the patch for this vulnerability. As an immediate workaround for deployments that cannot upgrade, disable OpenID sign-in by setting ENABLE_OPENID_SIGNIN = false in the [openid] section of the Gitea configuration file. Additionally, network-level controls such as egress firewall rules restricting the Gitea server's outbound HTTP access to internal IP ranges can reduce the exploitability and impact of this vulnerability in the interim (GitHub Advisory).

The vulnerability was reported by security researcher alimezar and remediated by Gitea maintainer bircni, who published the advisory on September 23, 2026. No significant broader media coverage or notable public researcher commentary beyond the official advisory has been identified at this time (GitHub Advisory).