The internal API HTTP client in Gitea (modules/private/internal.go) sets TLSClientConfig.InsecureSkipVerify to true with no option to disable this behavior, unlike other outbound TLS clients in Gitea which allow secure-by-default configurations. When LOCAL_ROOT_URL is set to an HTTPS URL pointing to a non-loopback host, the internal API client accepts any TLS certificate, including self-signed or invalid ones. This enables an attacker with network access to intercept and decrypt internal API calls, capturing the static INTERNAL_TOKEN used as the sole authentication mechanism for all internal API endpoints. These endpoints control critical functions such as server shutdown, SSH key authorization, git command execution, and more. The internal API client runs as a separate process and communicates over a real network socket, making interception feasible in split-host or multi-pod deployments. The vulnerability has been present since 2017 and affects all Gitea versions before 1.27.0. No official patch or remediation is indicated in the provided data.

An attacker with on-path access to the internal network segment where Gitea's internal API HTTPS calls occur can intercept and capture the static INTERNAL_TOKEN. This token is the sole authentication for all internal API endpoints, granting the attacker high-privilege access to sensitive operations including server shutdown/restart, SSH key authorization, git command execution, repository hooks, mail sending, and runner-token generation. In split-host or multi-pod deployments using HTTPS for internal API communication, this vulnerability is high severity. In single-host or loopback deployments, the risk is low or informational since local access is required to intercept the token, which is already exposed locally.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until an official fix is available, operators should avoid configuring Gitea's internal API communication over HTTPS to non-loopback hosts in split-host or multi-pod topologies. Using loopback or Unix socket communication for internal API calls mitigates the risk. Monitor vendor channels for updates addressing this hardcoded InsecureSkipVerify setting and consider restricting network access to internal API endpoints to trusted hosts only.