· via dev.to (home feed)
Gitea 28.1.0 closes 27 security flaws; finding exposed instances is the first job
Gitea's 28.0.0 and 28.1.0 releases fixed 27 vulnerabilities, including critical SSH and web installer bugs. A new analysis argues patching starts with inventorying your exposed self-hosted instances.

What the releases fixed
Gitea's 28.0.0 and 28.1.0 releases, counted together, closed 27 security issues. According to the dev.to analysis, which cites a SecurityOnline roundup, the set includes one Critical, four High and five Medium vulnerabilities, with the remainder unrated. None of them has confirmed exploitation in the wild.
The highest score in the batch, 9.1 on CVSS v3, belongs to CVE-2026-103059, which affects Gitea's built-in SSH server. CVE-2026-96404, scored 8.1, covers a web installer that can issue an administrator session without a password check. CVE-2026-103670, scored 7.5, allows a trusted workflow to be cancelled from an unapproved fork run and sits within the Actions-approval family of fixes.
The version picture matters here: installations on Gitea 1.27.3 or earlier carry all 27 issues once the two release trains are combined, while 28.0.0 still carries the eight issues that 28.1.0 went on to fix. The dev.to author's bottom line is that 28.1.0 is the upgrade target for every deployment, regardless of how it was installed.
Inventory before patching
The central argument of the analysis is that a Gitea upgrade is an inventory problem first and a patching problem second. A forge is usually one host per team or per organisation, set up by a developer rather than a platform group. That pattern produces fleets of small, long-lived, lightly documented installations: some built from a container image two years ago and never revisited, others running behind a reverse proxy on a well-known hostname.
The author contends that the difference in exposure between those two cases is larger than the severity differences among the CVEs in this release. Practically, a hostname list pulled from a load balancer's configuration will miss the instance someone stood up on a spare virtual machine and reached through a tunnel.
Reachable is not exploitable
The internet-facing part of the question can be answered with fingerprint data. Gitea's web interface presents characteristic responses in the HTML title, headers and static assets, and a host that matches the fingerprint while answering from a public address is discoverable by anyone running the same query.
Reachability, however, is not exploitability. CVE-2026-103670 requires fork workflows to be enabled, the other Actions issues need comparable configuration, and the SSH key flaw only applies where the built-in SSH server is in use. Each of those conditions narrows the exposed set, and none is visible from outside the host.
Sizing the exposed fleet
For a public-facing number, the analysis points to ZoomEye: a search for app="Gitea" matched 116,431 assets on 2026-10-07, measured against a threshold of 100. That figure describes hosts matching the Gitea fingerprint and says nothing about versions or configuration. Running the same query against an organisation's own address space, or against domain scopes for its registered domains, turns the public statistic into a candidate list.
The author also flags a false comfort to avoid: a ZoomEye query for the new CVE identifier returned no indexed assets, which is expected for a freshly published identifier and does not indicate any fleet is clean.
What operators should do
The recommended sequence is to build the list, then patch to 28.1.0. For the internet-facing subset, use external fingerprint data; for internal instances, combine network scanning with asset records. The analysis advises confirming the build number rather than the version string shown in the UI, since deployments sometimes pin a container tag that lags behind the actual binary.
For instances that cannot be upgraded immediately, the suggested mitigations are to keep the web installer unreachable, restrict migration and mirror creation, and require approval for fork pull request workflows.
Why it matters
A forge concentrates source code, pipeline tokens and deployment credentials on a single host, which makes the cost of a compromise high. The installer and SSH flaws in this batch reach administrative control, so one overlooked host can become a path into everything the pipelines can touch. As the analysis puts it, an unknown instance is an unpatched instance with a delay attached. With over 116,000 fingerprint-matched hosts visible in public scan data, the practical work for operators is narrowing that number down to their own estate and closing the gap to 28.1.0.
- #gitea
- #security
- #self-hosted
- #vulnerability-management
- #open-source