# Eight Thousand Git Servers Are Open for Business — and Attackers Know It
The whole point of self-hosting your Git infrastructure is control. You keep the code off someone else's cloud, you own the data, you manage the keys. For thousands of organizations running Gitea, that philosophy just became a liability. More than 8,300 internet-facing Gitea instances remain unpatched against a critical remote code execution vulnerability that attackers are actively exploiting — meaning the servers organizations trusted to keep their source code private are now handing over access to it.
Cybersecurity watchdog Shadowserver confirmed the ongoing exploitation, flagging that the majority of the exposure sits in vulnerable Gitea deployments that simply haven't been updated. The number — 8,300-plus — isn't a theoretical scan result. These are live, reachable servers. The patch exists. The attacks are real. The instances are just sitting there.
## Why Developer Tooling Is the Target Now
Gitea occupies a specific niche: it's the self-hosted Git service of choice for organizations that don't want GitHub, GitLab SaaS, or Bitbucket. Universities. Government agencies. Defense contractors. Research institutions. Smaller software shops with privacy requirements or air-gap ambitions. The common thread is that these organizations often set up infrastructure and then — in an industry cliché that keeps paying out — forget to maintain it.
That makes Gitea deployments a specific kind of target. An attacker who achieves remote code execution on a Git server doesn't just get a server. They get everything on it: source code, embedded credentials (because developers absolutely do still commit secrets), CI/CD pipeline configurations, deployment keys, webhook integrations, and sometimes direct pathways into build systems. A compromised Gitea instance isn't just an endpoint — it's a potential entry point into whatever that code touches next.
This is the supply chain threat playing out at the infrastructure layer, not the package registry layer. It's SolarWinds logic applied to self-hosted Git: own the repository server, own the pipeline downstream from it.
## The Self-Hosted Patch Gap
There's a well-documented pattern with self-hosted developer tooling, and it's ugly. Cloud-hosted services get patched by the vendor overnight. Self-hosted deployments depend on administrators who are — let's be honest — often developers or small IT teams running Gitea as one of fifty things they're responsible for. When a critical patch drops, it competes with everything else for attention. Sometimes it wins. Often it doesn't.
We've seen this with Jenkins, repeatedly. With older GitLab versions. With Confluence and Jira deployments that took months to patch against critical flaws even as active exploitation was confirmed. The 8,300 number here is actually consistent with historical patch adoption curves for self-hosted developer tooling — which means it's not an anomaly. It's the baseline failure mode.
The difference this time is that attackers aren't waiting. Exploitation started before most administrators even registered the advisory. The gap between patch availability and widespread adoption is the attack window, and on self-hosted infrastructure that window tends to stay open for weeks.
## What's Actually at Risk
Consider the typical Gitea deployment profile: a research institution hosting thesis code and faculty projects, with SSH keys and deployment tokens embedded in configuration files. A small software consultancy keeping client code on a self-managed instance. A municipal government IT shop that stood up Gitea three years ago to manage internal scripts and configuration files — some of which contain infrastructure credentials.
None of these organizations are running active threat monitoring on their Git servers. Most aren't watching for anomalous repository access patterns. Many haven't reviewed their Gitea instance since it was provisioned. An attacker executing code on that server could pivot laterally, exfiltrate the entire codebase and credential set, or implant malicious commits that get pulled into active build pipelines — quietly, without triggering anything downstream.
The blast radius isn't the server. It's everything the server touches.
## What Defenders Should Do Right Now
The immediate action is straightforward: patch. Gitea releases are available and the fix is confirmed. If you're running any version affected by this vulnerability, update now.
But the harder work is the audit that should follow the patch:
If you can't patch immediately, taking the instance offline or restricting it to internal network access is the right interim call. An unpatched, internet-exposed RCE is not a risk you want to carry for another cycle.
---
## HackWire Analysis
The 8,300 figure deserves some context: that's not a scan of everything on the internet. That's Shadowserver's view of publicly reachable Gitea servers that remain unpatched against an actively exploited critical flaw. The actual number of vulnerable deployments — including those behind corporate firewalls that are still exposed to lateral movement once an attacker is inside the perimeter — is almost certainly higher.
What's striking about this incident is how it exposes a persistent blind spot in organizational security posture: developer infrastructure. Security teams spend enormous energy hardening web applications, endpoints, and cloud infrastructure. The Git server is often treated as plumbing — critical, but not glamorous enough to make the vulnerability management priority list.
Attackers have clearly updated their mental model. The pivot from "compromise an endpoint to get to the code" to "compromise the code repository directly" is efficient. You skip several steps and land with higher-value access. This is why attacks against CI/CD systems — Jenkins, GitHub Actions misconfigurations, build pipeline manipulation — have accelerated over the past three years. Gitea is the same attack surface, just smaller and less monitored.
The organizations most exposed here are also the ones with the least capacity to respond quickly: research institutions, local governments, small engineering shops. A well-resourced enterprise almost certainly patched this already or doesn't run exposed Gitea. The tail of the distribution is everyone else, and that tail is long.
The lesson isn't just "patch faster" — it's that self-hosted developer tooling needs to be inside your vulnerability management program with the same rigor you apply to production web servers. It almost never is.
— HackWire Editorial
---
## Related Coverage