Gitea Servers on the Internet: 115,944 Found

Why port 3000 is not a complete inventory

Gitea may sit behind a reverse proxy, run on a custom port, or be exposed through a shared HTTPS endpoint. In those cases, the public connection might use port 443 even if the application is listening somewhere else internally. Network teams may also expose the service through an ingress controller, load balancer, or other intermediary.

That means port scanning is good for finding some deployments, but it's not a reliable way to prove you found them all. If an organization's asset inventory search only checks the default port, it can overlook instances that are reachable through a proxy or configured differently.

The same issue applies to internet asset search engines more generally: results depend on what they can observe, how they identify services, and when they last collected data. The counts describe matches at a specific point in time. They don't identify every Gitea deployment, and they don't tell you whether any given server is misconfigured.

What the numbers do not establish

A fingerprint match doesn't tell you whether an instance allows anonymous access, supports self-registration, or hosts repositories that should be private. It also doesn't establish the Gitea version, who owns the server, or whether it's vulnerable. Even worse, it doesn't show what an authenticated user could access.

These figures also exclude Gitea instances that aren't externally reachable. A service behind a corporate VPN, private network, or other access boundary may still matter, but it won't show up in a public-facing scan.

So keep the distinction straight: publicly discoverable is not the same as publicly readable, and publicly readable is not the same as compromised. Each condition needs its own evidence. For the original search-platform reference, see ZoomEye.

Registration and repository visibility

Start with registration policy. If an instance allows self-registration, an unknown visitor can create an account. That does not automatically mean they'll see private repositories - permissions still control access. But it does create an identity inside the service, and bad defaults, inherited permissions, or overly broad team memberships can turn that account into a path to information the organization intended to protect.

Next, check repository visibility defaults and the actual visibility of existing repositories. A common problem isn't a clever exploit; it's a mismatch between what teams think the service does and what it's actually configured to allow. For example, a team may assume newly created repositories are private, while the instance or the organization's settings set a different default.

Test the behavior directly with an account that has no special permissions. Don't rely only on an administrator's view - admins can see more than ordinary users, so their interface is a poor stand-in for anonymous or low-privilege access.

CI workflows and secrets

CI configuration can connect a Git service to build infrastructure, package registries, cloud accounts, or deployment targets. Gitea Actions supports workflow automation; the Gitea Actions overview covers the feature. A security review should focus on how credentials are scoped and exposed, not just on whether workflows exist.

Review at least:

• Which repositories and workflows can use each secret.
• Whether secrets are restricted to protected branches, environments, or trusted events where applicable.
• Which users can edit workflow files (and who can change the conditions under which workflows run).
• How logs are handled, including whether sensitive values could show up in command output or debugging traces.
• Whether credentials have only the permissions needed for their task, and whether they can be rotated independently.

Secret masking helps, but it shouldn't be treated as a guarantee that a value can never leak. Workflow changes, command output, and broad secret scope can still create exposure paths. The key question is what a workflow is allowed to do with a secret - and who can trigger that workflow.

Separate people and automation identities

An administrator account and a deployment (or automation) account do different jobs. If they're mixed, the impact of a compromised credential gets bigger, and it becomes harder to sort out which actions came from a person versus a process.

Use distinct identities, distinct authentication methods where practical, and permissions that match each role. Then compare your setup against the Gitea authentication documentation and the configuration cheat sheet to see what knobs exist for your instance.

This isn't about adding identity layers for their own sake. It's about limiting how many systems and permissions get pulled into the blast radius when a credential is exposed, misused, or just left behind after a person or integration changes.

1. Find instances through more than one route

Combine your existing asset inventory with network and application discovery. Check DNS records, reverse-proxy and ingress configuration, cloud load balancers, container platforms, and firewall rules. Search for the service fingerprint when it makes sense, but don't treat port 3000 as the whole definition of "a Gitea deployment."

For each candidate, capture its owner, environment, public endpoint, hosting location, and business purpose. Mark uncertain findings for follow-up instead of counting them as confirmed assets. An unowned service is a problem even before you decide whether its configuration is risky - nobody is clearly responsible for patching, access review, or decommissioning.

2. Test access from the right perspectives

Check the instance in at least three ways: no sign-in, a normal user account, and an administrator account. This separates what's publicly visible from what authenticated users can access, and it shows where privileged configuration might matter. Use a controlled test account and follow your organization's rules for security testing.

Confirm whether registration is enabled, what a new account can see, and whether repository visibility defaults match your policy. Review organization and team membership and also repository-specific permissions. A setting that looks harmless at the instance level can be undone by a team grant or an exception set on a particular repository.

3. Trace the path from repository to deployment

List the workflows and integrations that can build, publish, or deploy code. For each one, identify the identity it runs as, the secrets it can access, and what those credentials can reach. If a token can deploy to production, figure out who can alter the workflow that uses it and what checks must pass before the workflow runs.

This is where a small permissions mistake can land big. Read access to source code isn't automatically production access. But if someone can change a workflow that receives a broadly scoped deployment credential, the effective risk changes fast. The relationship between repository permissions, workflow triggers, and secret scope matters more than any single setting in isolation.

4. Turn findings into a repeatable control

Treat a one-time review as the start, not the end. Document the configuration decisions that matter, assign an owner, and decide how you'll detect changes over time. A practical baseline can include registration policy, repository visibility, administrator access, authentication methods, secret scope, workflow permissions, and public exposure.

Prioritize by combining reachability with impact. An internet-facing instance with public repositories may be expected and properly controlled. A private instance with self-registration, broad team permissions, and production credentials available to editable workflows needs a different response. You can't infer that from server counts alone - you need the configuration review.