CVE-2026-60004: Gitea Code Injection Vulnerability

What this software does

Gitea is a self-hosted Git forge — a lightweight alternative to GitHub or GitLab that you run on your own server. It hosts repositories, manages pull requests and issues, and provides a web interface for browsing code and collaborating. Because it's self-hosted, it often sits on a server that also holds other things, and the Gitea service account typically has filesystem access to the repositories it manages. If someone can run commands as that account, they can read, modify, or delete the repositories, and potentially reach other files on the same host depending on how the service is configured.

What went wrong

This is a code injection vulnerability in how Gitea processes patch data. The flaw lives in the diffpatch API endpoint, which is the component that applies incoming patches to repositories. An attacker who can write to a repository — meaning they have push access or can open a pull request — can craft a malicious patch that, when processed, plants an executable Git hook. Git hooks are scripts that Git runs automatically at certain points in the repository lifecycle, and Gitea executes them as its own service account. The result is that the attacker's shell commands run with the privileges of the Gitea service account.

The vulnerability requires no authentication and no user interaction to reach the endpoint itself, but the attacker does need repository write access to deliver the malicious patch. That precondition matters: a fully anonymous attacker cannot exploit this on a default setup where repositories require authentication to write to. The CVSS vector scores this as requiring no privileges at all, which conflicts with the upstream description's requirement for write access. Trust the description — the attacker needs an account with write permission to a repository, not just network access.

Why this one matters

This is listed in CISA's Known Exploited Vulnerabilities catalogue, which means it has been confirmed exploited in the wild. The EPSS probability of exploitation within 30 days is high, and the CVSS score is critical. What that combination means operationally is that automated scanning and exploitation tooling will already be targeting this flaw. If you run Gitea and have repositories that accept contributions from anyone beyond a small trusted team, the window between now and when you patch is the risk period. The severity rating matters less than the fact that this is a known, actively-used attack path against a widely deployed piece of infrastructure software. Patch it today, not this week.

Are you affected?

You are affected if you run Gitea with any repository that allows write access from users you do not fully trust. That includes:

• Repositories where multiple people can push directly.
• Repositories that accept pull requests from forks — the patch delivery mechanism works through the same endpoint.
• Any Gitea instance where you have enabled anonymous write access, though that is a non-default configuration.

If your Gitea instance is single-user, or every user with write access is someone you trust completely, your exposure is lower — but the endpoint is still reachable, and the cost of patching is small compared to the cost of a compromised service account.

How to fix it

The fix is an upstream release, not a distribution package. Your usual apt upgrade or yum update will not deliver this — Gitea ships its own releases, and you need to update the binary or container image yourself. The fixed version is in the table below.

Once you have the new version in place, do not assume the running service is patched. Gitea runs as a long-lived process, and an upgraded binary on disk does nothing until the service is restarted. Restart the Gitea service, then verify the version that the running service reports — not the version on disk. A common failure mode is a package that updates the files but never restarts the daemon, leaving the old, vulnerable process still serving requests.

If you cannot patch immediately

If you cannot update right now, the most effective mitigation is to restrict who can reach the Gitea web interface and API. Put the service behind a proxy or firewall rule that only allows connections from your trusted network or VPN. This does not fix the vulnerability, but it narrows the pool of people who can even attempt to exploit it.

The cost: anyone who needs to access Gitea from outside your trusted network loses access until you patch. If your team is fully remote and relies on Gitea being publicly reachable, this is a real operational hit — but it is a temporary one, and it is better than a compromised service account.

There is no way to disable the diffpatch endpoint without breaking repository collaboration, so do not attempt to work around it by turning off features. Patch, or restrict access.

How to tell if you were already targeted

Because this is confirmed exploited in the wild, checking for signs of compromise is worthwhile if you run a public instance. Look for Git hooks that you did not create. Hooks live in the .git/hooks directory of each repository on disk — files like pre-receive, post-receive, update, or pre-commit. A hook that contains shell commands you do not recognise, or that was modified recently, is a strong indicator.

Also check for scheduled tasks or cron jobs that reference the Gitea service account, and for outbound connections from the Gitea host to addresses that have no business being contacted. If you find anything suspicious, preserve the files and logs before deleting anything — copy the hook files and relevant logs to a separate location for analysis, then investigate what the hook was doing.

Reducing the blast radius

Run Gitea in a container or a dedicated user account with the minimum filesystem permissions it needs. The service account should not have write access to anything outside the directories it manages — if the account is compromised, the attacker's reach is limited to repositories, not the whole host.

Keep the Gitea data directory on a separate filesystem or volume from the operating system. If the service account is compromised, the attacker can still read and modify repositories, but they cannot tamper with system binaries or configuration.

Finally, review who has write access to your repositories periodically. Every account with push access is a potential entry point for this class of flaw. Fewer trusted writers means a smaller attack surface for the next vulnerability that requires write access to exploit.