Gitea’s RCE Is Now Exploited—Open Registration Widens the Door

A Canadian Centre for Cyber Security advisory records that CISA added CVE-2026-60004 to its Known Exploited Vulnerabilities catalog on August 25, 2026, and identifies Gitea releases before 1.27.1 as affected. Operators should move to a fixed release and treat exposed vulnerable instances as potential incidents, not merely patch-management findings.

The flaw does not give every anonymous visitor immediate command execution: the vulnerable operation requires repository write access. However, reporting published on August 26 describes an outdated instance where an automated scanner used open registration to create an account and repository before deploying a miner-like payload, demonstrating how an outsider can acquire the missing permission.

Write access is required—but it may be self-obtained

CVE-2026-60004 is not strictly a pre-authentication vulnerability. The request that triggers the vulnerable behavior must come from an account allowed to write to a repository or create an initialized repository under its control.

Gitea’s technical advisory identifies versions from 1.17 up to, but excluding, 1.27.1 as affected; it says the diffpatch endpoint can install and execute a Git hook as the Gitea operating-system user, with the documented trigger requiring Git 2.32 or newer, an enabled diffpatch route, and a writable and executable temporary filesystem. The advisory also explains that default open registration can let a visitor obtain the necessary write access by registering a normal account and creating a repository.

This distinction resolves the apparent conflict between “authenticated” and “unauthenticated” descriptions. The exploit request is authenticated, but the attacker may need no credentials beforehand if self-registration and repository creation are available without administrator approval. Closing registration removes that enrollment path; it neither repairs the vulnerable code nor protects against existing users, compromised accounts or tokens that already carry write permission.

Five conditions determine the documented exposure path

A version check establishes whether vulnerable code is present, but it does not describe the entire path to execution. A safe exposure review separates the following conditions:

• Gitea version: determine whether the running service falls within the affected range and verify the version of the active process, not merely a downloaded package or container image.
• Git runtime: check whether the installed Git release supports the three-way fallback used by the documented technique.
• diffpatch availability: establish whether the vulnerable route is enabled and reachable in the deployed configuration.
• Repository authority: identify accounts and tokens that can write to repositories or create initialized repositories.
• Registration policy: check whether an unknown visitor can self-enroll and gain repository-creation rights without prior approval.

The published chain also depends on temporary storage that is both writable and executable. Absence of one prerequisite may interrupt this specific technique, but it is not a durable alternative to patching: configuration can change, and an existing account may already satisfy the permission requirement.

The patch closes the vulnerability; registration controls one route

Operators should upgrade to the fixed release or a later maintained version, then confirm that the deployed service was replaced and restarted successfully. A staged image, cached package or completed download does not prove that the running Gitea process is no longer vulnerable.

Disabling public registration is a useful temporary reduction where open enrollment is unnecessary. Administrators should also review repository-creation policy and enumerate users, service accounts and automation tokens with write access. Email verification, CAPTCHA and approval controls may impede automated enrollment, but they do not neutralize the underlying flaw.

If a vulnerable instance was internet-reachable, immediate containment can include restricting access at the reverse proxy or network boundary, revoking suspicious sessions and tokens, and limiting unnecessary outbound connectivity from the Gitea service or container. These measures reduce exposure while remediation proceeds, but they do not replace the fixed software.

Incident review must extend beyond the miner-like payload

Commands execute with the Gitea service account’s privileges, so an investigation should not end when an unexpected process is removed. Depending on deployment isolation and permissions, the account may have access to application configuration, environment secrets, mounted repositories, database credentials, OAuth credentials and integration tokens.

Teams should preserve available logs and filesystem evidence before rebuilding an affected system. Relevant records include new accounts and repositories, authentication events, diffpatch requests, process starts, unexpected files, outbound connections and abnormal CPU use.

For containerized installations, the review should cover the container filesystem and runtime events as well as mounted volumes, the host, network controls and orchestrator logs. Restarting a container may remove an ephemeral process while leaving stolen credentials, altered repositories or modified mounted storage untouched.

Secret rotation should follow the service account’s possible reach. The scope may include Gitea application secrets, database credentials, personal and automation tokens, OAuth credentials, webhook secrets, deployment keys and CI/CD credentials. Resetting only user passwords would leave machine credentials and integrations exposed.

The publicly described payload is evidence of exploitation, not a complete threat profile. A hunt limited to cryptocurrency-mining indicators could miss credential theft, repository modification or other commands executed through the same service context.

The exploitation scale remains unknown

The KEV addition establishes that exploitation has occurred, but currently available government information does not identify the attackers, count compromised servers or tie the catalog decision to the publicly described miner-like incident. That incident demonstrates a workable open-registration route; it does not establish the size or uniformity of a broader campaign.

The confirmed position is narrower but operationally significant: vulnerable Gitea deployments need the fixed software, open registration can allow an outsider to become the repository writer required by the exploit chain, and secrets reachable by the service account belong within the incident boundary. Further vendor, government or forensic reporting would be needed to determine campaign scale, additional payloads or persistence methods.

Also read:

• Chrome Remote Desktop Is the Easy Route—No Open RDP Port Required
• The Internet Now Changes at the Border—313 Shutdowns Show the Cost
• Unitree Passed 5,000 Humanoid Shipments—Open Tools Explain Only Part of Its Rise