Gitea diffpatch Git hook installation enables remote code execution

Gitea before 1.27.1 allows remote code execution via the diffpatch API through Git hook installation.

• Gitea versions >=1.17, <1.27.1 are affected, corresponding to versions 1.17 through 1.27.0 in the vendor advisory.
• The vendor identifies Gitea 1.27.1 as patched for this issue.
• The affected record sets default_status to unaffected outside the stated range. The status of parallel branches, downstream packages, or forks is not established by the record and should be checked separately with the relevant vendor or packager.

The flaw is in services/repository/files/patch.go, where Gitea applies attacker-controlled patches in a shared bare temporary clone using Git apply with --index, --cached, and --binary, and adds -3 on Git 2.32 or newer. An add/add collision can cause Git's three-way fallback to check out a path from the patch even though the operation uses --cached. Because the root of a bare repository is $GIT_DIR, an executable file at hooks/post-index-change becomes a live Git hook. Git invokes the hook while writing the index, allowing repository-controlled content to execute shell commands as the Gitea OS user. The advisory identifies Git 2.32 or newer, an enabled diffpatch route, and a writable and executable temporary filesystem as conditions. The impact beyond the service account depends on host isolation and the permissions granted to the Gitea account.

The vulnerability is reachable over the network through the diffpatch API and does not require user interaction; the normalized record describes low attack complexity. Direct exploitation requires an account with repository write access. On installations with open registration and repository creation enabled, an unauthenticated visitor can register and obtain the required access. Exploitation also depends on the diffpatch route being enabled, Git 2.32 or newer, and a temporary filesystem that is writable and executable. The supplied record marks the vulnerability as known exploited and as having a public exploit; runZero also reports exploitation in the wild.

• The technical result is remote code execution as the Gitea OS user, corresponding to CWE-94 for improper control of code generation.
• An attacker may read, modify, or create data within the service account's permissions, including repositories, configuration, secrets, and internal services reachable from the host.
• Higher privileges, container escape, or impact to other systems are not established by the record; those outcomes depend on account permissions, host configuration, and isolation controls.
• The issue can therefore affect confidentiality, integrity, and availability, but it should not be treated as guaranteed full host control in every deployment.

• An attacker may execute arbitrary commands with the Gitea service account's permissions and may therefore access app.ini, process environment secrets, mounted repositories, database credentials and contents, and OAuth or integration credentials when those resources are reachable.
• Repository content or build outputs may be modified, creating integrity risks for source code, pipelines, and downstream artifacts.
• Services or host resources reachable by the Gitea account may be altered or disrupted.
• The result is execution within the permissions of the Gitea OS user; it does not by itself prove root access or control of every connected system.

1. Upgrade Gitea to exactly 1.27.1, which the vendor identifies as the patched release. After upgrading, verify that the deployed binary or package is the intended version.
2. If an immediate upgrade is not possible, temporarily reduce exposure by disabling open registration where it is not required, restricting repository creation, and limiting repository write access to trusted accounts. These measures reduce risk but do not replace the patch.
3. Verify the diffpatch route, Git runtime, and temporary filesystem permissions on remaining instances to determine exposure.
4. If exploitation indicators are found, isolate the instance under incident response procedures, assess the service account's permissions, and review secrets, credentials, repositories, and databases reachable by that account.
5. If there is evidence that secrets or credentials were accessed, rotate them within the affected scope and review repositories, pipelines, and artifacts for unauthorized changes.

1. Inventory every self-hosted Gitea deployment and verify its exact version; flag versions from 1.17 through before 1.27.1 for remediation.
2. Identify instances where the diffpatch route is enabled, Git 2.32 or newer is in use, and the temporary filesystem permits writing and execution.
3. Review HTTP access logs for unusual requests to POST /api/v1/repos/{owner}/{repo}/diffpatch. This is a precautionary investigation and monitoring measure, not a vendor-confirmed IOC.
4. Inspect Gitea repository storage and temporary areas for unexpected executable Git hooks, especially hooks/post-index-change.
5. Review process telemetry around the Gitea service account for unusual shells or child processes created near diffpatch requests.
6. If exploitation is suspected, assess exposure of app.ini, process environment secrets, mounted repositories, database credentials, OAuth credentials, and integration credentials; the absence of suspicious logs or hooks does not prove that the system is safe.