Critical Gitea Flaw Lets a Self-Registered Account Turn a Git Patch Into Remote Code Execution
A critical Gitea vulnerability lets a repository writer convert a crafted patch into a live Git hook and run shell commands as the service account.
Overview
Gitea, the self-hosted Git platform, has patched a critical remote code execution vulnerability that lets anyone with ordinary repository write access run arbitrary shell commands as the server’s own service account, according to a GitHub security advisory. Because Gitea enables open registration by default, an outside visitor can obtain that write access simply by signing up and creating a repository, then exploit the bug with no prior credentials, the advisory says.
The flaw is tracked as CVE-2026-60004 and carries a CVSS score of 9.8 out of 10, with the vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, per the advisory. It is classified under CWE-94, improper control of code generation, and affects Gitea versions 1.17 through 1.27.0. Gitea shipped the fix in version 1.27.1, according to the release notes.
What We Know
- The vulnerable code lives in
services/repository/files/patch.go, which applies attacker-controlled patches inside a shared bare temporary clone, according to the advisory. - The advisory describes the exploit mechanism: submitting the same patch twice creates an “add/add collision,” and Git’s three-way merge fallback checks the indexed path out even though the operation is performed with the
--cachedflag. - Because the temporary clone is bare, the repository root is the Git directory itself. That means an executable file submitted at the path
hooks/post-index-changebecomes a live Git hook, which Git then invokes while writing the index — executing attacker-controlled content as the Gitea service account, the advisory states. - The advisory notes the hook’s return value is never propagated back to the
diffpatchAPI response, and the proof-of-concept code that accompanies the advisory stores command output inside Git objects and pushes it to a branch, so the attack requires no outbound network connection from the compromised server — the result is instead retrieved later over authenticated smart HTTP. - Exploitation requires Git 2.32 or newer, an enabled
diffpatchAPI route, and a writable, executable temporary filesystem on the server, according to the advisory. Open registration is only needed for the no-prior-credentials version of the attack. - Depending on how a given Gitea instance is isolated and what privileges its service account holds, the advisory says successful exploitation could expose the
app.iniconfiguration file and application secrets, process environment variables, mounted repositories, database credentials and contents, OAuth and integration credentials, and other internal or externally reachable services. - The Hacker News reports that Gitea said on July 27 that Gitea Cloud instances would be upgraded automatically, and that disabling open registration can remove the public account-creation path while an installation waits to be patched — but does not fix the underlying flaw or stop an existing user with write access from exploiting it.
- The vulnerability was reported by a researcher using the handle NightRang3r, credited as the reporter on the advisory, which was published July 28, 2026 — one day after Gitea shipped version 1.27.1 on July 27, according to the advisory and release timestamps.
- Notably, the release notes for 1.27.1 list the fix for this flaw only under a “MISC” heading, as “refactor: git patch apply,” rather than under the “SECURITY” section, which that same release reserves for an unrelated fix enforcing mandatory two-factor authentication on OAuth2 endpoints.
What We Don’t Know
- Neither the advisory nor The Hacker News’ report states that the flaw has been exploited in the wild; The Hacker News notes the advisory does not claim active exploitation, though public proof-of-concept code now exists.
- It is not disclosed how many self-hosted Gitea instances remain unpatched or continue running with open registration enabled.
Analysis
The bug’s severity comes less from technical sophistication than from a default configuration choice: Gitea ships with open registration on, so the “repository write access” the advisory says is required is trivial for any visitor to obtain on an unmodified installation. Pairing that with a changelog entry that gives no hint of a security fix means self-hosted administrators scanning release notes for a reason to prioritize the upgrade would have found none — the only line flagged “SECURITY” in version 1.27.1 concerns OAuth2 two-factor enforcement, not the remote-code-execution path.