Published: Thu 27 Aug 2026
Prepared by: Brandon Sawyer, Vulnerability Analyst
Purpose
On 28 July 2026, Gitea disclosed CVE-2026-60004, a critical remote code execution (RCE) vulnerability affecting Gitea, a widely used self-hosted Git service. The vulnerability allows an attacker to execute arbitrary operating system commands as the user account running the Gitea service. On 25 August 2026, the US Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-60004 to its Known Exploited Vulnerabilities (KEV) catalogue, confirming that the vulnerability is being actively exploited in the wild. Organisations operating internet-facing or self-hosted Gitea instances should treat remediation as an urgent priority.
Vulnerability Details
CVE-2026-60004 is a code injection vulnerability (CWE-94) in Gitea's diffpatch functionality. The vulnerability affects Gitea versions 1.17 through 1.27.0, and has been assigned a CVSSv3.1 base score of 9.8 (Critical). The issue was remediated in Gitea version 1.27.1, released 28 July 2026.
The vulnerability exists within the POST /api/v1/repos/{owner}/{repo}/diffpatch endpoint. When processing threat actor-controlled patch content, Gitea applies patches inside a shared, bare temporary Git clone using git apply with the --index, --recount, --cached and --binary options (with a three-way merge fallback added on Git 2.32 and later). By submitting a specially crafted patch that sets the file path to hooks/post-index-change and resubmitting it a second time, a threat actor can trigger Git's three-way merge fallback behaviour and write an executable Git hook into the repository's active hook directory. Git subsequently executes the hook automatically during the index update, resulting in arbitrary command execution as the Gitea operating system account.
Exploitation requires an authenticated account with repository write permissions. However, Gitea enables user self-registration by default. In unmodified deployments, a remote threat actor without prior credentials can typically register a new account, create a repository, and obtain the permissions necessary to exploit the vulnerability. Disabling self-registration reduces this exposure but does not prevent exploitation by existing users or compromised accounts, so it should not be relied upon as a substitute for patching.
Successful exploitation can expose sensitive resources accessible to the Gitea service account, including application configuration files, secrets, environment variables, repository data, database credentials, OAuth tokens, and integration credentials. The ultimate impact depends on the privileges granted to the Gitea service account and the broader environment in which Gitea operates.
On 25 August 2026, CISA added the vulnerability to its KEV catalogue based on evidence of active exploitation, with a remediation due date of 28 August 2026. Organisations should therefore assume the vulnerability is being targeted by threat actors and prioritise remediation accordingly.
Discovery and Disclosure Timeline
| Date | Event |
| 28 Jul 2026 | Gitea publishes security advisory GHSA-rcr6-4jqh-j84m for CVE-2026-60004 and releases version 1.27.1 containing a fix. |
| 29 Jul 2026 | Public technical details and proof-of-concept (PoC) code become available. |
| 10 Aug 2026 | Independent security researchers publish a working exploit tool for CVE-2026-60004, increasing the likelihood of widespread exploitation attempts. |
| 25 Aug 2026 | CISA adds CVE-2026-60004 to the KEV catalogue, confirming active exploitation, with a remediation due date of 28 August 2026. |
| Ongoing | Security researchers and vendors continue monitoring exploitation activity and providing guidance. |
Impact
Successful exploitation allows a threat actor to execute arbitrary operating system commands as the account running the Gitea service. Depending on the environment, this may provide access to:
- Application secrets and configuration files.
- Source code repositories and project data hosted within Gitea.
- Database credentials and connected backend systems.
- OAuth tokens, API credentials, and third-party integration secrets.
- Build pipelines, deployment infrastructure, and software supply chain assets accessible through the compromised service account.
Because Gitea commonly hosts source code and development workflows, compromise may allow a threat actor to tamper with software projects, steal intellectual property, or establish persistence within development environments.
Mitigation
Primary Remediation
The primary remediation is to upgrade affected Gitea installations to Gitea 1.27.1 or later. All versions from 1.17 through 1.27.0 should be considered vulnerable.
As active exploitation has been confirmed, organisations should not assume that patching alone is sufficient. Any internet-facing instance that remained vulnerable after public disclosure on 28 July 2026, particularly after the release of working exploit tooling in mid-August, should be reviewed for indicators of compromise and unauthorised activity regardless of current patch status.
Compensating Controls
Where immediate patching is not possible, organisations should disable open user registration, restrict repository creation to trusted users only, limit access to Gitea through VPNs, reverse proxies, or trusted network segments, and review accounts with repository write access to remove any unnecessary permissions.
These measures reduce exposure but do not eliminate the vulnerability. Upgrading remains the only complete remediation.
Hardening and Longer-Term Actions
Organisations should run Gitea using a dedicated, least-privileged service account, rotate credentials, tokens, and secrets accessible to the Gitea service if compromise is suspected, review repository activity and administrative actions for signs of unauthorised access, and ensure logging is centrally collected and retained to support incident investigation.
Detection
Indicators and Detection Activities
Administrators should perform the following activities:
- Review newly created user accounts, particularly on instances where self-registration was enabled.
- Investigate recently created or modified repositories that were not expected by administrators.
- Examine system and application logs for unusual activity associated with the diffpatch endpoint.
- Review process execution logs for unexpected commands running under the Gitea service account.
- Investigate any evidence of unauthorised repository modifications, branch creation, or unusual Git hook activity.
Recommended Hunting Activities
- Identify all Gitea instances running versions 1.17 to 1.27.0.
- Review user registrations and repository creation events dating back to the 28 July 2026 disclosure.
- Correlate Gitea logs with system telemetry to identify potential command execution activity.
- Conduct credential rotation where compromise cannot be ruled out.
- Initiate incident response procedures if suspicious activity is identified.
Organisations that have questions regarding the identification, investigation, or remediation of CVE-2026-60004 should refer to the official Gitea security advisory and seek assistance through Gitea's community support channels where required.
MDR customers: Triskele Labs will continue tuning detections and analysing IOCs for behaviours consistent with the exploitation of CVE-2026-60004 across supported log sources.
Vulnerability Management customers: Environments are being assessed for vulnerable versions of Gitea affected by CVE-2026-60004. Any findings will be communicated through priority channels.
