Gitea: 116,010 fingerprints against 120,024 titles, and the self-hosted forge as an identity boundary

Gitea is small enough to run on a single board and complete enough to hold the keys to an organisation's software supply chain. That combination explains why it appears so often on the public internet: it is easy to deploy, pleasant to use, and frequently stood up by a team that never asks whether the forge should be globally reachable.

What the queries returned

Measured on 29 September 2026 through ZoomEye's API, sub_type=all, page 1, pagesize=1:

Dork	Field	Total matches
app="Gitea"	Application fingerprint	116,010
title="Gitea"	HTML title	120,024

The values are close, which is what one expects from a product that renders its own name on every installation's landing page and also exposes a recognisable fingerprint. Close agreement between two fields is the kind of consistency that makes a count easier to use than the large divergences seen with CouchDB or Elasticsearch.

What a forge actually holds

A repository host is an identity boundary. It authenticates developers, authorises their pushes, stores deploy keys and personal access tokens, and often brokers continuous-integration webhooks into production systems.

Three assets make an exposed instance significant. The source code itself is the obvious one, including any private repository a team assumed was internal. The credentials are the second: SSH deploy keys that grant write access to a production host, tokens that can trigger a deployment pipeline, and stored webhook secrets that authenticate inbound build requests. The user database is the third, because a forge account frequently becomes a single sign-on identity for other internal tools.

Gitea has also published security releases addressing authentication and access-control defects over the years, which is normal for software of this size and is precisely why version matters when an instance is publicly reachable.

Reading these two counts

A fingerprint or title match establishes that a Gitea instance was visible to the scanner. It does not establish that registration is open, that private repositories are readable, or that any given account is weak.

Registration policy is the detail most often overlooked. An instance configured to allow self-registration and then published to the internet acquires accounts from anyone who finds it, and those accounts can read every repository visible to a default user.

Neither count reports version, and neither can say whether a match is a public open-source forge that is meant to be reachable or an internal instance that leaked into public DNS.

These are single observations. No earlier measurement with an identical query is being compared, so nothing here supports a growth claim.

Practical steps

Decide first whether the instance is public by design. If it is, confirm that self-registration is either disabled or requires administrator approval, and that new accounts see nothing until they are granted access.

If it is not meant to be public, find out how it became reachable: an old DNS record, a port forward, or a cloud load balancer left in place after a migration. Remove the path rather than relying on authentication alone.

Then inventory the secrets inside it. List deploy keys and access tokens, confirm each is scoped to a single repository, rotate anything that grants write access to a production system, and verify that webhook secrets are not shared between repositories.

References

1. Gitea documentation, https://docs.gitea.com/
2. ZoomEye AI asset search, https://www.zoomeye.ai/