The CVE added by CISA on August 25, 2026 is CVE-2026-60004, a critical remote code execution vulnerability in Gitea. CISA’s addition of the flaw to the Known Exploited Vulnerabilities catalog confirms that this is no longer merely a theoretical weakness. The vulnerability is being exploited in the wild and therefore deserves immediate remediation priority. It is rated CVSS 9.8 and affects Gitea versions from 1.17 up to, but not including, 1.27.1. Gitea 1.27.1 contains the fix.

The vulnerability is particularly serious because it allows repository-controlled content to be converted into operating-system command execution on the Gitea server. The weakness exists in Gitea’s `diffpatch` functionality and is tracked as CWE-94, Improper Control of Generation of Code. An attacker with repository write access can abuse the endpoint to cause a Git hook to be installed into a temporary bare Git repository used internally by Gitea. Git subsequently executes that hook, giving the attacker arbitrary command execution with the privileges of the operating-system account running Gitea.

The underlying attack is unusual because the attacker is not exploiting a conventional command-injection parameter or uploading an executable directly. Instead, they manipulate Git’s normal repository-processing behaviour. Gitea’s `diffpatch` endpoint applies attacker-controlled patches to a temporary bare repository. Under specific circumstances, conflicting patches can cause Git’s three-way merge fallback to write attacker-controlled content into the bare repository.

Because the root of a bare repository effectively acts as its Git metadata directory, an attacker can cause an executable file to appear inside the repository’s `hooks` directory. Git then treats that file as a real hook and executes it during later repository processing.

This is what makes CVE-2026-60004 more significant than a normal repository-integrity problem. Git hooks are programs that Git automatically executes when certain repository events occur. They are deliberately powerful because developers use them for automation. If an attacker can create an executable hook inside a repository that Gitea itself later processes, user-controlled source content has crossed an important trust boundary and become executable server-side code.

The attack specifically involves the `post-index-change` hook. Once the crafted patch causes an executable entry to be created at that location, Git invokes the hook during its normal processing, allowing arbitrary commands to run as the Gitea service account.

The privilege requirement deserves careful interpretation. The exploit requires repository write access, but on Gitea servers where public registration is enabled, an Internet user may be able to register a normal account and create a repository immediately. In such a configuration, the practical attack path can become almost unauthenticated because the attacker can obtain the required low-level privilege themselves.

Where registration is disabled, the vulnerability still matters because any low-privileged authenticated user with repository creation or write access may potentially exploit it. This makes the flaw relevant not only to public Internet-facing Gitea instances but also to internal development platforms shared with contractors, developers, partners or students.

Successful exploitation runs commands using the privileges of the Gitea operating-system account. The actual impact therefore depends heavily on how that account and host are configured. The attacker may potentially access application configuration, process environment variables, mounted repositories, database credentials, database contents, OAuth credentials, integration secrets and other services reachable from the Gitea server.

This is potentially devastating because source-code management platforms are unusually valuable targets. A Gitea server may contain proprietary source code, deployment scripts, CI/CD credentials, webhook secrets, package repository credentials, SSH keys, API tokens and database passwords.

The source-code supply-chain risk is especially important. If attackers obtain command execution as the Gitea service account, they may be able to modify repositories, tamper with build scripts, insert malicious dependencies or alter code that is subsequently built and deployed elsewhere.

A compromise that begins on one development server can therefore propagate into production through completely legitimate CI/CD mechanisms. This is one of the reasons source-control platforms should be considered critical security infrastructure rather than ordinary developer utilities.

The vulnerability has several environmental prerequisites. Exploitation requires a compatible Git version, the vulnerable `diffpatch` route and a temporary filesystem that is writable and executable. Public registration is required only for the attacker to obtain repository write access without already possessing an account.

These conditions are useful for exposure assessment, but they should not be treated as reasons to postpone patching. The affected version range is very broad, covering Gitea releases from 1.17 through 1.27.0.

The public disclosure timeline also increases the urgency. Gitea released version 1.27.1 with the security fix before CISA added the vulnerability to KEV. Technical details and proof-of-concept information subsequently became public, and CISA’s August 25 addition confirms that attackers are now exploiting the flaw.

Once a vulnerability enters KEV, vulnerability management should no longer be driven mainly by theoretical exploitability or the CVSS number. Someone is actually using it. At that point, the main questions are whether the vulnerable feature exists in the environment, whether it is reachable and whether the attacker may already have arrived.

The immediate remediation is straightforward: upgrade Gitea to version 1.27.1 or later. Organisations running substantially older deployments should consider moving to a currently supported version rather than expecting indefinite security maintenance on legacy releases.

Patching alone, however, is not enough for systems that were exposed while vulnerable. CVE-2026-60004 provides operating-system command execution. Updating the application prevents the original exploit from being used again, but it does not remove a backdoor, stolen credential, malicious repository change or persistence mechanism created before the update.

Security teams should review Gitea access and API logs for unusual use of the `diffpatch` endpoint, especially repeated patch submissions associated with newly created repositories or accounts.

Publicly registered accounts created shortly before suspicious activity deserve extra scrutiny. A sequence consisting of account creation, repository creation and unusual `diffpatch` requests may provide useful behavioural evidence of attempted exploitation.

Investigators should also examine temporary directories used by Gitea for suspicious Git hook files or unusual repository structures. Because temporary repositories may be automatically cleaned up, forensic artefacts can disappear quickly. This makes centralised endpoint, process and audit telemetry particularly valuable.

Process monitoring should look for unexpected child processes launched by Gitea or Git. Gitea legitimately invokes Git frequently, so seeing Git processes alone is meaningless. The important events are Git or Gitea spawning shells, PowerShell, scripting interpreters, download utilities, network tools or system-administration commands that are inconsistent with normal repository activity.

Outbound network activity should also be reviewed, but the absence of suspicious external connections does not prove exploitation did not occur. An attacker may be able to execute commands, store the output inside Git repository objects and retrieve that information through normal Gitea traffic.

This makes CVE-2026-60004 awkward for traditional exfiltration monitoring because command output can potentially travel through legitimate repository operations rather than through a new command-and-control connection.

Repository history should therefore be examined for unusual branches, commits, references or short-lived repositories created during the suspected exposure period. Unexpected changes to build scripts, deployment workflows, Dockerfiles, dependency manifests and CI/CD configuration deserve particular attention.

The Gitea configuration file is another important area. It may contain database connection details, security settings or other secrets depending on deployment practice. If an attacker achieved command execution as the Gitea service account, those values should be considered potentially exposed.

Database credentials should similarly be reviewed and rotated where compromise is suspected. The Gitea application account may have broad access to repository metadata, users, tokens, webhooks and integration information.

OAuth tokens, webhook secrets and integration credentials may also need rotation. Source-control platforms are frequently connected to CI/CD systems, issue trackers, artifact registries, cloud environments and deployment platforms. A successful attacker may therefore use the compromised Gitea server as a stepping stone into several connected systems.

SSH keys deserve equal attention. Depending on deployment, the Gitea service may manage authorised keys, repository SSH access or other key material. Security teams should identify keys created or changed during the exposure period and revoke anything not clearly attributable to legitimate administration.

Repository integrity should be independently validated. Important repositories should be compared with trusted copies, signed releases or known-good commits where possible.

Code-signing keys should ideally never be directly accessible to the Gitea service account. If compromise of the repository platform also exposes signing keys, attackers may be able to make malicious software appear legitimately released.

Running Gitea under a dedicated unprivileged operating-system account is extremely important. The exploit inherits the permissions of the Gitea process. If Gitea is running as root, the attacker effectively receives root-level command execution.

Containerisation can reduce the blast radius, but only if the container is properly restricted. A Gitea container should not run in privileged mode, mount unnecessary host filesystems or expose the Docker socket. A container with unrestricted access to `/var/run/docker.sock` can often be converted into control of the underlying host.

Temporary filesystem configuration can also provide defence in depth. Because exploitation depends on creating and executing a Git hook inside temporary storage, mounting appropriate temporary directories with restrictive execution policies may reduce exposure in some environments. This should be tested carefully and should not be treated as an alternative to patching.

Public registration should be disabled on private Gitea deployments unless there is a legitimate operational need. CVE-2026-60004 demonstrates how a vulnerability that nominally requires low-level repository privileges can become effectively Internet exploitable if anyone can self-register and immediately create a repository.

Where public registration is required, new accounts should receive the minimum capabilities necessary. Email verification, repository quotas, abuse controls and behavioural monitoring can increase the difficulty of automated exploitation.

Network exposure should also be reconsidered. Internal source-control systems do not need to be directly Internet accessible merely for convenience. Remote developers can access them through VPN, ZTNA or identity-aware access mechanisms where appropriate.

A firewall, WAF or NGFW can provide useful additional detection around suspicious API behaviour, but signature-based controls should not be considered the main remediation. The core weakness involves legitimate Git patch-processing behaviour rather than one fixed malicious payload.

Rate limiting and behavioural analysis can still help. A newly registered account that immediately creates a repository and repeatedly calls unusual patch-processing APIs does not resemble normal developer behaviour and can be flagged even if each individual HTTP request looks technically valid.

The vulnerability also provides a strong secure-development lesson around temporary repositories. Temporary workspaces are often assumed to be safe because they are short-lived. In reality, if attacker-controlled content is placed into a temporary structure that another tool interprets semantically, the temporary directory may become an execution environment.

Git repositories are not simply collections of files. Hooks, configuration, attributes, submodules and helper mechanisms can alter behaviour. Applications integrating Git therefore need to understand the security semantics of repository internals rather than treating every repository path as passive data.

The same principle applies to package managers, archive utilities, notebook platforms, build tools and CI/CD systems. Security reviewers need to understand how downstream software interprets attacker-controlled metadata, not merely search application code for obvious command execution calls.

CVE-2026-60004 also reinforces why development infrastructure deserves Tier-0 or near-Tier-0 protection in many environments. A Git platform may not host production customer data directly, but control of the source code can influence what ultimately reaches production.

Source-control platforms should therefore receive strong authentication, rapid security updates, endpoint monitoring, network segmentation, configuration backups and centralised audit logging.

Administrative access should use strong MFA where supported, and service integrations should rely on narrowly scoped credentials rather than long-lived shared secrets.

Outbound connectivity from the Gitea server should also be restricted to destinations genuinely required for normal operation. Egress filtering will not stop every exploitation technique, but it reduces the attacker’s ability to retrieve secondary payloads or establish command-and-control channels.

Backups must be isolated from the production Gitea environment. If the same compromised account can modify both live repositories and backups, the organisation has little meaningful recovery separation.

Backups should also be checked for integrity before being trusted. A backup created after attackers altered source code faithfully preserves the malicious changes.

The KEV addition demonstrates an important vulnerability-management principle: CVSS should be combined with exploitation intelligence, asset importance and exposure.

A vulnerable Internet-facing Gitea instance with open registration and access to valuable repositories deserves far higher priority than an equally scored vulnerability on an isolated system with no realistic attacker path.

For organisations running Gitea, the immediate response should therefore be layered: upgrade all installations below version 1.27.1, identify whether public registration is enabled, review access to the `diffpatch` functionality, inspect newly created accounts and repositories, hunt for abnormal Gitea or Git child processes, review repository history, rotate application and integration credentials where exploitation is suspected, validate source-code integrity and ensure Gitea runs under a restricted service identity.

Internet-facing systems should receive the highest priority, but internal systems must not be ignored. A compromised workstation, stolen VPN credential or malicious insider may already provide the repository write access necessary to exploit an internal deployment.

The broader lesson from CVE-2026-60004 is that developer platforms are not merely storage systems for source code. They execute Git operations, connect to databases, trigger CI/CD systems, manage credentials and occupy a privileged position inside the software supply chain.

The most concerning aspect is how ordinary the initial attacker capability can be. On a system allowing open registration, the attacker may begin as nothing more than a newly created Gitea user with their own repository.

From there, vulnerable patch processing can turn permission to store code into permission to execute code on the server.

That is the security boundary CVE-2026-60004 breaks. Gitea intended to let users control repository content, not the operating system running the platform. Once those two privileges become equivalent, the impact extends far beyond one Git repository and potentially into the organisation’s entire development and deployment chain.

CISA has added one new vulnerability to its Known Exploited Vulnerabilities (KEV) Catalog , based on evidence of active exploitation. CVE-2026-60004 Gitea Code Injection Vulnerability This type of vulnerability is a frequent attack vector for malicious cyber actors and poses significant risks to the federal enterprise. Binding Operational Directive (BOD) 26-04: Prioritizing Security Updates Based on Risk establishes vulnerability management requirements for Federal Civilian Executive Branch (FCEB) agencies. BOD 26-04 reinforces the importance of the KEV Catalog and requires federal agencies to prioritize rapid remediation of high-risk vulnerabilities, specifically those identified by Common Vulnerabilities and Exposures (CVEs) listed in CISA’s KEV Catalog on publicly exposed assets that grant total control of the asset post-exploitation, while deferring action for lower-risk vulnerabilities. BOD 26-04 further establishes basic expectations for when agencies must check whether threat actors compromised the system before the patch was applied. While BOD 26-04 applies only to FCEB agencies, CISA encourages all organizations to adopt risk-based vulnerability management and prioritize remediation of KEV Catalog vulnerabilities . CISA will continue to add vulnerabilities to the catalog that meet the specified criteria . Aware of an exploited vulnerability not currently listed in the KEV Catalog? Submit it for potential addition through CISA’s KEV Nomination Form . Potential KEV add

Source: CISA Adds One Known Exploited Vulnerability to Catalog via CISA Advisories — published 25 Aug 2026.