Sizing a self-hosted forge: finding Gitea instances before you patch

To properly manage security patches for self-hosted Gitea installations, one must first identify all instances of the software running within an organization. This process is crucial because the vendor cannot determine the exact number of Gitea instances deployed nor which of them are accessible via the internet. The release notes for Gitea versions 28.0.0 and 28.1.0 mention the resolution of 27 security issues, including CVE-2026-103670, a medium severity vulnerability that requires trusted workflow cancellation and an unapproved fork.

Before patching, it is essential to have a comprehensive inventory of all Gitea instances. The vulnerabilities are categorized as Critical, High, Medium, and unrated, with a total of 27 issues present across Gitea 1.27.3 and earlier versions. Among these, CVE-2026-103670 has a CVSS v3 score of 7.5 and CVE-2026-103059 has the highest score of 9.1, affecting the built-in SSH server.

The highest CVSS score in the set is 9.1, indicating a critical security flaw. The distributed nature of Gitea deployments, often set up by individual developers rather than platform groups, results in a large number of small, long-lived, and lightly documented installations. Some of these instances may have been set up from a container image two years ago and have not been updated since.

The exposure of these instances varies significantly, depending on whether they are internet-facing or not. Publicly accessible instances can be identified through fingerprint data, such as the HTML title, headers, and static assets of the web interface. However, even these instances require additional configuration to be exploitable.

For example, CVE-2026-103670 needs fork workflows enabled, and the other Actions items need comparable configuration. The SSH key flaw requires the built-in SSH server to be in use. Each of these conditions narrows down the set of vulnerable instances, but none of them can be detected from outside the organization. The impact of a compromised forge is significant, as it could lead to the compromise of source code, pipeline tokens, and deployment credentials.

The installer and SSH key flaws grant administrative control, turning one overlooked host into a potential entry point into the entire network. To address this issue, organizations should build a list of all Gitea instances using external fingerprint data for internet-facing instances and network scanning plus asset records for internal instances.

This list should then be patched to Gitea 28.1.0. It is recommended to use external fingerprint data for the internet-facing subset and network scanning plus asset records for the internal instances. Instances that cannot be upgraded this week should have their web installer unreachable, migration and mirror creation restricted, and approval required for fork pull request workflows.