CISA Orders Federal Agencies to Patch an Actively Exploited Gitea Flaw by August 28
CISA added a critical Gitea code injection flaw to its Known Exploited Vulnerabilities catalog after a self-hosted instance was hit with a cryptojacking-style attack, giving federal agencies until...
The Cybersecurity and Infrastructure Security Agency has given federal agencies until August 28 to patch a critical remote code execution flaw in Gitea, the self-hosted, open source alternative to GitHub that developers use to run their own Git hosting, code review, and CI/CD platform without depending on a third-party service.
Table Of Content
CISA added the flaw, tracked as CVE-2026-60004, to its Known Exploited Vulnerabilities catalog on August 25 under the name “Gitea Code Injection Vulnerability.” The agency’s own KEV catalog entry describes it directly: “Gitea contains a code injection vulnerability that allows an attacker with repository write access to send a malicious patch to the diffpatch API endpoint to plant an executable Git hook and run shell commands as the Gitea service account.” The bug carries a CVSS score of 9.8 out of 10 and falls under CWE-94, the weakness category for code injection.
How a patch review turns into a shell
The flaw lives in Gitea’s diffpatch endpoint, the API that applies an uploaded patch to a repository. According to the GitHub security advisory Gitea published on July 28, an attacker who submits the same patch twice creates what the advisory calls an “add/add collision.” When Git’s three-way merge logic falls back to resolving that collision, it checks out the indexed path even though the operation is supposed to be index-only. In a bare repository clone where $GIT_DIR equals the repository root, that checkout can drop an executable file at hooks/post-index-change, a real Git hook location. Git then runs that hook automatically the next time it writes the index, executing whatever commands the attacker embedded, as the Gitea service account.
The bug needs Git 2.32 or newer, an enabled diffpatch route, and a writable, executable temporary filesystem: conditions most default Gitea installations meet. It only requires ordinary repository write access, not an administrator account. Gitea allows open self-registration by default, so on an unmodified installation, an anonymous visitor can register a normal account, create a repository, and reach the vulnerable endpoint without ever being handed valid credentials.
A cryptojacking dropper, not just a proof of concept
CISA only adds vulnerabilities to the KEV catalog when it has evidence of real-world exploitation, and in this case a documented example exists. A full-stack developer using the handle @Causelof described on the Russian blogging platform Habr, in an account picked up by The Hacker News, how their own self-hosted Gitea instance was compromised through this exact flaw. The developer, who goes by Andrey, said their hosting provider flagged the server for pushing CPU usage above 70 percent for an extended stretch, a terms-of-service violation that triggered automatic throttling.
Investigating the alert, Andrey found the instance had several settings enabled that made it an easy target: open registration, no required email confirmation, OpenID signup, and public visibility with no forced sign-in. “A new user could register, create their own repository, and obtain the necessary write permissions within it,” Andrey wrote. The dropper that ran afterward cleared security-related environment variables, searched for and killed other high-CPU processes (likely to free up resources for its own workload), then fetched an architecture-specific payload, executed it, and deleted the evidence. Andrey said the behavior “lines up with a cryptojacking campaign,” while cautioning that they had not analyzed the payload itself and could not confirm which mining pool, wallet, or malware family was involved, or who was behind it.
Gitea’s third disclosed flaw this year
This is not the first Gitea vulnerability to make headlines in 2026. In May, researchers disclosed CVE-2026-27771, an access-control failure that exposed private container images on an estimated 31,750 internet-facing Gitea deployments to unauthenticated pulls. In July, sxz.io covered a separate flaw, CVE-2026-20896, that attackers were caught actively probing within two weeks of disclosure: a wildcard default in Gitea’s official Docker images let anyone who could reach a container’s HTTP port impersonate any user, including admins, with a single forged HTTP header.
CVE-2026-60004 shares no root cause with either earlier bug. It is a distinct code-execution path through the patch-review feature, fixed in a different release. Taken together, though, the three disclosures point to the same underlying pressure: a self-hosted Git platform concentrates an enormous amount of trust, source code, CI/CD secrets, deploy keys, and database credentials, behind a web application that, like any other, accumulates edge cases across years of feature development.
What Gitea admins should do now
Gitea shipped the fix in version 1.27.1, released July 27 alongside a fix for a second, unrelated flaw: an unauthenticated arbitrary file read via the Org-mode #+INCLUDE directive, tracked as CVE-2026-59774. Every Gitea release from 1.17 up to but not including 1.27.1 is affected, a span of roughly four years of releases. Gitea’s own advisory for the diffpatch bug credits security researcher NightRang3r as the reporter; the release announcement also thanks researcher xbow-security alongside NightRang3r for the two vulnerabilities fixed in 1.27.1 overall, with the fixes themselves developed by contributors wxiaoguang and TheFox0x7 as part of a batch of 48 merged pull requests.
Administrators who cannot upgrade immediately should treat open registration as the most urgent setting to lock down: disabling self-registration, requiring email confirmation, and turning off public, no-sign-in visibility all raise the bar for an outside attacker to reach the vulnerable endpoint in the first place. CISA’s guidance is clear, though, that patching is the required remediation, not a configuration workaround. Federal civilian agencies must apply the fix by August 28 under Binding Operational Directive 26-04, or discontinue use of the product if a fix cannot be applied in time. Private organizations running self-hosted Gitea, especially any instance reachable from the open internet, should treat that same date as a practical floor rather than a ceiling: unlike a coordinated disclosure with no evidence of exploitation, this bug already has at least one documented victim.
Sources and image credit
- SecurityWeek: CISA Warns of Exploited Gitea Vulnerability
- CISA: Known Exploited Vulnerabilities Catalog
- GitHub Security Advisory: GHSA-rcr6-4jqh-j84m (CVE-2026-60004)
- The Hacker News: Critical Gitea RCE Actively Exploited as Reported Attack Drops Miner-Like Payload
- Gitea Blog: Gitea 1.27.1 is released
- Featured image: Lifting hook with a safety latch hanging from a bridge crane by W.carter, CC0 1.0 Public Domain, via Wikimedia Commons.








No Comment! Be the first one.