Critical Gitea RCE Is Under Active Exploitation — Your Git Server May Already Be Running Someone Else’s Code

• The Mess: A critical vulnerability tracked as CVE-2026-60004 is reportedly being actively exploited against Gitea servers, putting self-hosted Git infrastructure at risk of remote code execution and potential server takeover.

The vulnerability was patched less than a month ago. Now it is being actively exploited.

CISA added CVE-2026-60004 to its Known Exploited Vulnerabilities catalog based on evidence of real-world attacks. The flaw carries a CVSS score of 9.8 and affects self-hosted Gitea versions from 1.17 through 1.27.0.

The Bug Lives Inside Gitea’s Git Workflow

The vulnerable component is Gitea’s diffpatch functionality.

An attacker with repository write access can submit a specially crafted patch that causes an executable Git hook to be written into the underlying repository environment. When Git processes the hook, arbitrary shell commands can run with the privileges of the operating-system account used by Gitea.

Normally, “requires repository write access” might sound like a useful security barrier.

Not necessarily.

On installations with open self-registration enabled, an outside attacker may be able to create an ordinary account, create a repository and obtain the access needed to trigger the vulnerable path.

So the attack can become:

Internet → register account → create repository → malicious patch → Git hook → code execution.

Attackers Are Already Using It

This is no longer a theoretical proof of concept.

Reports of exploitation describe attackers abusing CVE-2026-60004 and deploying a payload described as miner-like, apparently after gaining command execution on the vulnerable server. CISA’s KEV addition independently confirms that exploitation is occurring in the wild.

And that’s the part administrators should care about.

Your Gitea server doesn’t just contain source code.

Depending on the deployment, it may also have access to:

• application secrets;
• database credentials;
• OAuth tokens;
• API keys;
• CI/CD integrations;
• repository contents;
• build infrastructure;
• internal services.

Compromise the Git server and the attacker may get much more than Git.

Why This Can Turn Into a Supply-Chain Problem

A compromised Gitea instance can be particularly dangerous because source code repositories often sit upstream from production systems.

Attackers may not need to attack the production server directly.

They could potentially target:

source code → build pipeline → software artifact → production.

That makes Git infrastructure a very attractive target.

A web server compromise is bad.

A compromised source-control server can potentially affect everything built from it.

The Fix Is Already Available

The affected range includes Gitea 1.17 through 1.27.0.

The vulnerability is fixed in Gitea 1.27.1 and later.

So the immediate response is straightforward:

upgrade.

But because exploitation is already happening, patching alone may not be enough.

If Your Server Was Exposed, Check for Compromise

Administrators should review:

• unexpected repository hooks;
• suspicious files in Git hook directories;
• unusual processes running as the Gitea service account;
• unexplained CPU usage;
• suspicious outbound connections;
• recently created user accounts;
• unexpected repositories;
• unusual API activity around the diffpatch functionality;
• access to secrets or configuration files by the Gitea service account.

And if suspicious activity is discovered:

assume credentials accessible to the Gitea service account may have been exposed.

Rotate them.

That includes database credentials, API tokens, OAuth secrets and CI/CD credentials where applicable.

The vulnerability can be patched.

A stolen secret remains stolen.

This Is the Problem With Developer Infrastructure

Gitea often doesn’t get the same attention as a public web application or VPN gateway.

Sometimes it runs:

inside a development network.

on a small cloud server.

behind a reverse proxy.

under the control of one engineering team.

And that can create blind spots.

The server is “just Git.”

Until somebody gets RCE on it.

Then suddenly your “just Git server” has access to repositories, deployment credentials and potentially the entire software delivery chain.

Bugstoday Opinion

This is exactly why active exploitation matters more than another scary CVSS number.

There are thousands of vulnerabilities with dramatic scores.

Most don’t get exploited.

This one already is.

And Gitea makes an especially interesting target because attackers aren’t necessarily compromising a random Linux box.

They’re potentially compromising the place where an organization stores the instructions for building its software.

That’s a very different kind of foothold.

Bugstoday verdict: CVE-2026-60004 turns a writable repository into a possible path to shell access on the Gitea server, and attackers have already started testing that path in the real world. If you’re running self-hosted Gitea below 1.27.1, patch it now — then check whether someone was already mining something other than your source code.