A Gitea Code-Injection Bug Is Being Exploited — Patch, Then Assume the Worst

What actually happened

CISA added CVE-2026-60004, described as a Gitea code injection vulnerability, to its Known Exploited Vulnerabilities catalog on 25 August 2026. The KEV listing is the important part: CISA doesn't add things to that catalog on theory. It adds them when there's evidence of active exploitation in the wild. So this isn't "a bug was disclosed" — it's "somebody is using this against real servers right now."

BleepingComputer, reporting separately, puts the count of exposed, vulnerable instances at more than 8,300. I only have their headline, so I won't pretend to know how they scoped that number, but the order of magnitude matches what you'd expect for a popular self-hosted forge that people stand up on a spare VM and then stop thinking about.

What neither source I have gives me is the detail you actually want before you touch anything: the exact affected versions, the fixed release, or the mechanics of the injection. CISA's alert names the CVE and nothing more. So the honest position today is: confirm the fixed version against Gitea's own release notes before you upgrade, don't take a version number from a blog — including this one.

Why this one lands on your desk specifically

Gitea is the sort of software this blog's readers run themselves. Unlike a hosted Git service where someone else eats the 3 a.m. page, a self-hosted forge is entirely your problem to patch. And people don't treat it like a mail server. A Gitea box tends to get less monitoring, sits on an internal VLAN "that nobody can reach anyway," and holds deploy keys, CI tokens, and the source for half your infrastructure. Code execution on that host is not a contained incident — it's a foothold into everything the repos can deploy to.

If your Gitea is genuinely internal-only, with no path from the internet, your exposure is lower than the 8,300 headline suggests. That's a real mitigating fact, not a get-out-of-jail card: the KEV entry describes active exploitation, and the population being scanned is the publicly reachable one. Reason about your own instance honestly — is it behind a reverse proxy that's exposed, is it reachable over a VPN split-tunnel, does a runner talk to it from a network that touches the outside world?

The part the KEV listing quietly demands

CISA's own BOD 26-04 — which binds federal agencies, but reads as sound advice for the rest of us — makes a point worth stealing. It sets an expectation that agencies check whether the system was already compromised before the patch went on. That's the discipline to borrow here. Because a vulnerability is under active exploitation, upgrading only closes the door going forward. It says nothing about who walked through it last week.

So the job is two steps, not one. Get onto a fixed Gitea release once you've confirmed the version from the project. Then treat the host as possibly-touched: review access logs and authentication events, look at when your admin accounts and tokens were last used, rotate the secrets that Gitea can reach — deploy keys, CI credentials, webhook tokens — and check for repos or hooks that changed without a human behind them. A code-injection flaw plus git hooks is a tidy persistence mechanism, so a clean patch with dirty credentials still left behind is not a fixed server.

If you can afford the downtime, take Gitea off the public internet entirely until you've done both. It should probably have been there all along.

Sources

• BleepingComputer — Over 8,300 Gitea servers vulnerable to code execution attacks
• CISA Advisories — CISA Adds One Known Exploited Vulnerability to Catalog