Gitea CVE-2026-60004 Is Now Actively Exploited — Attackers Deploy Cryptominers

• The Mess: A critical vulnerability in self-hosted Gitea servers is now being actively exploited in the wild. Tracked as CVE-2026-60004, the flaw allows arbitrary command execution through the diffpatch API and Git hooks. A real-world attack has already been observed deploying a cryptocurrency-mining payload on a vulnerable Gitea server.

This is no longer a theoretical vulnerability.

It’s no longer:

“There is a PoC, patch when you have time.”

CISA added CVE-2026-60004 to its Known Exploited Vulnerabilities catalog on August 25, confirming exploitation in the wild.

And that changes the situation completely.

The Vulnerability

CVE-2026-60004 is a code-injection vulnerability in Gitea’s diffpatch API.

An attacker with repository write access can submit a specially crafted patch that causes a malicious Git hook to be placed inside the repository.

When the hook executes, the attacker can run arbitrary shell commands with the privileges of the Gitea service account.

That’s effectively remote code execution against the server.

The vulnerable versions are Gitea versions before 1.27.1. Gitea released 1.27.1 on July 27 to address the flaw.

And There Is a Nasty Configuration Problem

The vulnerability technically requires an authenticated user with repository write access.

That sounds like a useful security barrier.

But default Gitea configurations can make that barrier surprisingly weak.

Gitea allows user registration by default in some configurations.

An attacker can potentially:

create an account

↓

create a repository

↓

obtain write access

↓

trigger the vulnerable endpoint

↓

execute commands

BleepingComputer specifically notes that open registration can effectively eliminate the need for pre-existing credentials.

So the phrase:

“requires authentication”

should not automatically make administrators comfortable.

The real question is:

Who can create an account?

Attackers Are Already Using It

This is the part that changes the urgency.

CISA has classified the vulnerability as actively exploited.

A documented incident involving a self-hosted Gitea instance showed attackers exploiting CVE-2026-60004 and subsequently deploying a cryptocurrency-miner-like payload.

The initial symptom wasn’t necessarily:

“Someone hacked my Git server.”

It was abnormal CPU consumption.

The compromised server was reportedly consuming more than 70% processor capacity, which eventually triggered attention from the hosting provider.

That’s a classic low-profile post-exploitation strategy.

Don’t immediately destroy the machine.

Don’t cause an obvious outage.

Just use someone else’s CPU to make money.

Cryptomining Is Probably the Least Interesting Outcome

A miner may be the payload that gets noticed first.

But it shouldn’t be interpreted as the maximum damage possible.

Once an attacker can execute commands as the Gitea service account, they may potentially access:

• repositories;
• Git history;
• CI/CD configuration;
• deployment credentials;
• API keys;
• SSH keys;
• webhook configuration;
• other secrets available to that account.

And that’s where this vulnerability becomes much more serious than:

“Someone is stealing CPU cycles.”

The compromised Git server can sit directly in the middle of an organization’s software-development workflow.

The Supply-Chain Risk Is the Real Problem

Gitea isn’t just another web application.

For many organizations it is the place where source code lives.

It can also trigger automated builds and deployment pipelines.

That creates a potentially dangerous chain:

Gitea compromise

↓

repository manipulation

↓

CI/CD pipeline

↓

build

↓

deployment

If attackers can influence code or pipeline configuration, the incident can potentially move downstream.

The initial victim doesn’t necessarily have to be the final target.

That’s why compromises of developer infrastructure deserve special attention.

Nearly 5,000 Gitea Instances Are Internet-Exposed

Shadowserver is currently tracking close to 5,000 Gitea instances reachable from the public Internet.

That number should not be interpreted as “5,000 vulnerable servers” — some may already be patched and some may be research honeypots.

But it demonstrates how large the externally reachable attack surface is.

And unlike a SaaS platform, self-hosted Gitea deployments depend on individual administrators to patch and secure them.

That’s where things often go wrong.

A server gets installed.

The development team starts using it.

It becomes part of the infrastructure.

And eventually:

nobody remembers who is responsible for updating it.

The Patch Has Been Available for Weeks

This is perhaps the most frustrating part.

Gitea released the fix on July 27.

The vulnerability was subsequently added to CISA’s KEV catalog on August 25 after exploitation was confirmed.

So organizations had a window to patch before attackers were publicly confirmed to be exploiting the flaw.

That window is now gone.

If you’re running an affected version:

this isn’t a “patch during the next maintenance cycle” situation.

Check Your Version

The first thing administrators should do is determine the exact Gitea version running on every instance.

The relevant boundary is:

before 1.27.1 → vulnerable

1.27.1 or later → patched against this vulnerability

Gitea has also released subsequent versions, so administrators should use the latest supported release rather than stopping indefinitely at the minimum security version.

And don’t forget development environments.

A forgotten staging Gitea instance can be just as useful to an attacker as the production system.

Don’t Stop at Patching

This is the part many administrators miss.

If your Gitea server was exposed to the Internet while vulnerable, patching doesn’t tell you whether someone already exploited it.

You should investigate.

Look for:

• unexpected Git hooks;
• unknown repositories;
• newly created accounts;
• unfamiliar SSH keys;
• suspicious commits;
• unexpected changes to CI/CD files;
• unusual outbound connections;
• unknown binaries;
• high CPU usage;
• unexpected cron jobs;
• suspicious processes running under the Gitea account.

And if compromise is suspected, rotate credentials that were accessible from the Gitea environment.

That includes deployment keys and API tokens.

Open Registration Should Be Reconsidered

If your Gitea instance is intended for a defined group of developers, there is little reason to allow unrestricted public registration.

Disabling registration reduces the attack surface.

But it is not a substitute for patching.

An attacker who already has a legitimate account with repository write permissions can still potentially exploit the vulnerability.

The goal should therefore be:

patch + restrict access + monitor.

Not:

disable registration and forget about it.

Why This One Deserves Attention

Gitea sits at an unusual position in the infrastructure stack.

It’s simultaneously:

application

source-code repository

developer platform

automation trigger

potential supply-chain component.

That makes compromise much more valuable than compromising an ordinary web server.

A web server might contain customer data.

A compromised Git platform can potentially provide the attacker with the blueprint for how the organization’s software is built and deployed.

That’s a very different kind of access.

Bugstoday Opinion

When we first looked at CVE-2026-60004, the interesting part was the combination of a public PoC and the unusually dangerous Git-hook exploitation path.

Now we have something much stronger:

CISA has confirmed exploitation.

And we have a real-world example of attackers using the vulnerability to deploy a mining payload.

The miner itself isn’t what worries me most.

It’s what happens if the next attacker decides that CPU mining isn’t enough.

Instead of:

miner

we could see:

credential theft

source-code theft

CI/CD manipulation

persistent backdoor

or eventually:

supply-chain compromise.

That’s why this vulnerability deserves attention even from organizations that don’t consider their Gitea server “production.”

Bugstoday verdict: CVE-2026-60004 has moved from vulnerability management to incident-response territory. The patch has been available since July, CISA now confirms active exploitation, and attackers have already demonstrated a practical path from Gitea compromise to malware deployment. If you run self-hosted Gitea, don’t just update it — check whether someone got there before you did.