Gitea Under Active Attack: CISA Adds Critical RCE Flaw to Exploited Catalog

Let me ask you something: Would you leave your office door unlocked, let anyone create a key, and then give that person access to your filing cabinets?

Of course you wouldn’t. But that is similar to what can happen when a self-hosted Gitea installation is exposed to the internet with open registration and an unpatched security flaw.

On August 25, 2026, the Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-60004 to its Known Exploited Vulnerabilities (KEV) catalog. The vulnerability carries a CVSS score of 9.8, allows remote code execution, and is already being exploited in the wild.

If your business self-hosts Gitea, this is not a vulnerability to place in the “we’ll get to it later” pile.

What is CVE-2026-60004?

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

Gitea is an open-source platform used to host Git repositories, manage code, review changes, and collaborate on software projects. Many small businesses use it internally or host it on their own servers because it gives them control over their development environment and data.

Here’s the problem: an attacker with repository write access can send a specially crafted patch through the vulnerable endpoint.

That patch can plant an executable Git hook inside the repository. A Git hook is an automated script that runs when certain repository actions occur. In this case, the malicious hook can execute arbitrary shell commands as the Gitea service account.

In plain language, an attacker may be able to turn a repository change into a way to run commands on the server.

And here’s where it gets more serious: default Gitea installations with open self-registration may allow an unauthenticated attacker to:

Create a new Gitea account.
Create a repository.
Obtain the repository access needed for exploitation.
Trigger malicious activity through the vulnerable API.

That means a weakness that technically requires repository write access can become effectively unauthenticated remote code execution on poorly configured, internet-facing systems.

Which Gitea versions are affected?

Gitea versions from 1.17 through 1.27.0 are affected.

The vulnerability is fixed in Gitea 1.27.1. The Gitea security advisory recommends upgrading, and the Gitea 1.27.1 release announcement provides additional release information.

If you are running a version earlier than 1.27.1, assume the installation is vulnerable until you upgrade or confirm that the system is not affected through a qualified technical review.

IT professional carefully reviewing a self-hosted server and laptop during a security update

Do you run Gitea through Docker, a virtual machine, or a managed Linux service? Check every instance. It is easy to update the primary server while leaving a forgotten development, backup, or testing instance exposed.

Why CISA’s KEV listing matters

CISA’s Known Exploited Vulnerabilities catalog is not simply a list of theoretical software bugs. It tracks vulnerabilities for which there is evidence of exploitation in the wild.

That changes the priority.

A vulnerability can be serious without being actively targeted. Once it appears in the KEV catalog, however, attackers are known to be using it or have demonstrated practical exploitation.

CISA lists CVE-2026-60004 with a remediation due date of August 28, 2026 for federal agencies under Binding Operational Directive 22-01. Small businesses are not federal agencies, but the deadline provides a useful warning: this issue requires immediate attention.

And there is another important detail. Current exploitation has included the deployment of cryptocurrency miner payloads.

A crypto miner may not immediately encrypt your files or display a ransom note. Instead, it quietly consumes CPU resources, increases cloud or electricity costs, slows applications, and gives an attacker a foothold that could later be used for more damaging activity.

A slow server is not always a hardware problem.

What could an attacker do after exploitation?

The Gitea service account’s permissions limit the initial reach of the attacker. But “limited” does not mean harmless.

Once arbitrary commands can run on the host, an attacker may attempt to:

Deploy cryptocurrency mining software.
Read configuration files and environment variables.
Search for database credentials, API keys, or access tokens.
Modify repositories or inject malicious code.
Establish persistence for future access.
Move from the Gitea server into other systems.
Use the compromised server to attack additional infrastructure.

The actual impact depends on how the server is configured, what the Gitea account can access, whether secrets are stored locally, and how well the host is isolated from the rest of your network.

Think of it like finding an unlocked side door. The intruder may enter through that door, but what they can reach next depends on how many interior doors are also unlocked.

What you should do now

Start by identifying every Gitea installation your business owns or manages.

Then work through these steps.

1. Upgrade to Gitea 1.27.1 or later

Upgrade vulnerable installations immediately to Gitea 1.27.1 or a later supported release.

Before making changes:

Confirm the current version.
Back up repositories and configuration data.
Review the vendor’s upgrade instructions.
Test the update where practical.
Verify the version after the upgrade.
Confirm all containers, replicas, and secondary nodes are updated.

Do not assume that restarting a container updated the application. Check the actual Gitea version running inside it.

2. Disable open self-registration if you do not need it

If anyone can create an account on your Gitea server, disable self-registration unless it is truly required.

Use controlled invitations or administrator-created accounts instead. Review existing accounts and remove users who no longer need access.

Keycard access at a secure office door with server equipment visible beyond the glass

It makes sense to prioritize convenience during setup. But a public registration page on an internet-facing development server can create unnecessary exposure, especially when combined with a critical vulnerability.

3. Restrict access to trusted users and networks

Your Gitea server does not need to be publicly reachable just because remote employees or contractors use it.

Consider:

Restricting access through a VPN or zero-trust gateway.
Allowing only approved IP addresses where practical.
Placing Gitea behind a properly configured reverse proxy.
Enforcing multifactor authentication for administrator accounts.
Separating the Gitea host from production systems.
Limiting outbound network access from the server.

The goal is simple: reduce the number of people and systems that can reach the service.

4. Review repositories, accounts, and logs

Because this vulnerability is actively exploited, patching alone may not be enough.

Review activity from the period when the server was running a vulnerable version. Look for:

Unexpected accounts or repositories.
Repositories created without a clear business reason.
Unfamiliar collaborators or permission changes.
Suspicious commits, branches, or tags.
Unexpected Git hooks.
API requests involving the diffpatch endpoint.
Unusual CPU, memory, or network usage.
Cryptocurrency miner processes or unfamiliar binaries.
Outbound connections to unknown destinations.

If you find evidence of compromise, isolate the server before deleting files or rebuilding it. Preserve logs and relevant evidence for analysis.

And do not assume that removing a miner removes the attacker. The miner may be only one part of the intrusion.

Two IT professionals monitoring abstract security charts and network activity in a modern office

How Platinum Web Services can help

For a small business, reviewing application versions, server permissions, repository activity, logs, and network exposure can become complicated quickly.

That is where a proactive approach matters. Platinum Web Services helps businesses review their technology environment, prioritize urgent updates, strengthen access controls, and monitor for suspicious activity.

Our cybersecurity solutions are designed around your business, not a one-size-fits-all checklist. We can also help evaluate managed IT services, cloud environments, endpoint protection, and network security controls.

If you are unsure whether your business operates a vulnerable Gitea instance, start with an inventory. Find the server, confirm the version, check whether registration is open, and determine whether the service is exposed to the internet.

The good news is that the fix is available.

Upgrade to Gitea 1.27.1 or later, close unnecessary access points, and investigate suspicious activity before treating the issue as resolved. If you would like help, contact Platinum Web Services. We provide support 24/7.