Gitea RCE Is Being Exploited. Attackers Are Already Dropping Payloads

• The Mess: A critical Gitea vulnerability, CVE-2026-60004, is now under active exploitation. The bug lets an attacker with repository write access abuse the diffpatch API to plant and execute a malicious Git hook, running shell commands as the Gitea service account. CISA added the flaw to its Known Exploited Vulnerabilities catalog after evidence of real-world exploitation.

The interesting part is how little access an attacker may actually need.

The vulnerability requires write access to a repository.

Normally that sounds like a limitation.

But many Gitea instances allow open registration.

So an attacker can potentially:

Create an account.

Create a repository.

Get write access to that repository.

Then use the vulnerable API.

No stolen admin password required.

No SSH access.

No complicated privilege escalation chain.

Just a malicious patch abusing Git’s own hook mechanism. The hook gets written into repository-controlled storage and later executes with the privileges of the Gitea service process.

Affected versions include Gitea 1.17 through 1.27.0.

The fixed release is 1.27.1.

And this is no longer a theoretical problem.

A reported real-world attack against a vulnerable Gitea instance used the flaw to deploy a dropper associated with unusually high CPU usage and a miner-like payload. The exact second-stage malware has not been independently identified, but the activity is consistent with cryptojacking.

That means the timeline has moved from:

Critical CVE → patch available

to:

Critical CVE → attackers are already using it.

• The Damage: Successful exploitation gives attackers arbitrary command execution as the Gitea service user, potentially exposing repositories, credentials, API tokens, CI/CD secrets and anything else the compromised Gitea process can access.

That can get ugly fast.

A self-hosted Git server is rarely just a Git server.

It often contains source code.

Deployment keys.

Access tokens.

CI secrets.

Configuration files.

Sometimes credentials that can open the door to production infrastructure.

So an attacker who lands on the Gitea server may not stop there.

They can start reading repositories.

Stealing secrets.

Modifying code.

Or poisoning the software supply chain.

That’s what makes a Git hosting RCE more interesting than a random web server crash.

You are not just protecting one application.

You may be protecting the entire development pipeline.

The active exploitation reports also make one thing painfully obvious:

open registration is a much bigger problem when a critical vulnerability only requires a writable repository.

What looks like a low-privilege bug can become effectively internet-reachable with a simple sign-up form.

• The Fix: Upgrade Gitea to version 1.27.1 or later immediately, and treat internet-exposed instances with open registration enabled as potential compromise candidates if they were running a vulnerable version.

Also check what happened before you patched.

Look for:

• unexpected Git hooks,
• suspicious processes launched by the Gitea service account,
• unusual CPU usage,
• unexpected downloads or outbound connections,
• recently created accounts and repositories,
• strange activity around the diffpatch API.

CISA’s KEV listing means this is not a “patch it next maintenance window” bug.

This is a do it now bug.

Bugstoday Opinion

This is the part where “requires authentication” stops sounding reassuring.

If your Gitea instance allows anyone to register, authentication is basically just a form.

Fill it in.

Create a repo.

Get write access.

Run code on the server.

Attackers have already moved past the theory and into payload delivery.

And when the compromised server hosts your source code and deployment secrets, a miner might be the least interesting thing an attacker decides to run.

Bugstoday verdict: update Gitea to 1.27.1 now. Your Git server should store your code — not execute someone else’s.