Who is affected
Gitea installations are affected by a code injection vulnerability in the diffpatch API endpoint. The vulnerability requires an attacker to have write access to a repository; they can then exploit this to inject and execute shell commands with the privileges of the Gitea service account. The record does not specify which Gitea versions are vulnerable or whether self-hosted and cloud-hosted instances are equally at risk.
How to check whether this touches you
- Inventory whether you operate or depend on Gitea instances in your environment, including any managed or cloud-hosted deployments.
- Establish whether your Gitea instance accepts repository contributions from untrusted users or whether all writers are internal staff you control.
- Check your network perimeter to confirm whether the Gitea web interface and API are reachable from the internet or restricted to internal networks only.
- Query your Gitea logs for any use of the diffpatch API endpoint over the past six to twelve months; this is the attack surface for this vulnerability.
- Contact your Gitea vendor or check the Gitea project advisories to confirm the exact version you are running and whether a patch or mitigation is available for it.
What to do
- Immediately review the Gitea project's official security advisory and vendor guidance to identify whether your version is affected and what patch or mitigation is available.
- If you cannot patch immediately, restrict write access to repositories to trusted internal users only; audit and revoke any external or service account credentials that have repository write permissions.
- If your Gitea instance is internet-facing, move it behind a firewall, VPN, or reverse proxy that requires authentication before the web interface is reachable; this reduces the window for exploitation.
- Enable comprehensive audit logging on your Gitea instance to capture all API requests to the diffpatch endpoint, repository writes, and Git hook creation events.
- Plan to apply the vendor's patch or mitigation within the timescale specified in CISA BOD 26-04; if no patch is available, escalate to your security team and evaluate whether continued operation of Gitea is acceptable for your risk profile.
If you find you were exposed
Exploitation of this vulnerability is likely to predate the public disclosure; conduct a retrospective search of your Gitea audit logs and system logs for the past six to twelve months for suspicious diffpatch API calls, unusual Git hook creation, and unexpected shell command execution by the Gitea service account. Retain and analyse logs from any repositories to which untrusted users had write access. If you lack sufficient log retention to cover the period since the vulnerability was introduced, document the gap and escalate to your incident response team for further investigation using filesystem and process forensics on the Gitea host.