CVE-2026-60004 (CVSS 9.8): Any Gitea User Can Hijack Your Server — A Public PoC Just Made Self-Hosted Git a Ticking Clock

The first thing you notice about CVE-2026-60004 is its CVSS score: 9.8 Critical. The second thing you notice is that “requires write access to a repository” sounds like a meaningful barrier — until you remember that the default Gitea installation ships with open user registration enabled. That means any internet-facing Gitea server, left at its factory defaults, can be fully compromised by an attacker who spends thirty seconds creating a free account. A working proof-of-concept was published alongside the 28 July 2026 security advisory by the researcher who found the flaw. The upgrade window is already measured in hours, not days.

For IT security teams running self-hosted Gitea — a popular open-source Git platform used extensively across Indian software companies, fintech firms, and government technology projects — this is an all-hands moment. Source code repositories are not just code storage; they are the master keys to your software supply chain, your CI/CD pipelines, your deployment credentials, and — very often — your production secrets.

What Is CVE-2026-60004?

Gitea is a self-hosted Git service written in Go, widely adopted as an on-premises alternative to GitHub Enterprise or GitLab CE. Organisations choose it for data sovereignty, customisation, and lower licensing cost. It powers internal developer workflows, integrates with CI/CD runners, and — critically — stores every secret that gets accidentally (or deliberately) committed to any repository on the server.

CVE-2026-60004 is a remote code execution vulnerability in Gitea’s diff-patch API endpoint, discovered by security researcher Shai Rod, known online as NightRang3r. Rod responsibly disclosed the flaw to the Gitea project, which merged a fix on 26 July 2026, backported it the same day, and released version 1.27.1 on 27 July. One day later, the security advisory and a working proof-of-concept dropped simultaneously — giving the global community of self-hosted Gitea operators exactly 24 hours of patched-but-unpublicised safety before the PoC became public knowledge.

The vulnerability affects every Gitea release from version 1.17 through 1.27.0. If your Gitea server is more than a day behind on updates — a situation that describes the overwhelming majority of self-hosted deployments anywhere in the world — it is presently exploitable by anyone who can reach its web interface.

Inside the Exploit — Git Hook Injection in Four Steps

To understand CVE-2026-60004, you need to understand one low-level Git mechanic: hooks. Git hooks are executable scripts that run automatically at specific lifecycle events. The hook at hooks/post-index-change, introduced in Git 2.32 (April 2021), fires whenever the repository index is updated. If an attacker can plant an arbitrary file at that path and mark it executable, every subsequent Git index operation becomes a code-execution opportunity — on the server, as the process owner.

The exploit targets Gitea’s diffpatch API: POST /api/v1/repos/{owner}/{repo}/diffpatch. This endpoint accepts a unified diff and applies it to the repository. The attack unfolds as follows:

1. Create an add/add conflict: The attacker submits the same patch file twice in rapid succession, creating a situation where Git sees two conflicting “add” operations for the same path.
2. Trigger the three-way merge fallback: Gitea’s patch-application logic, unable to resolve the conflict cleanly, falls back to a three-way merge process that materialises a temporary working tree.
3. Exploit the path validation flaw: Through a logic error in how the merge result is handled, the attacker-controlled content is written to .git/hooks/post-index-change inside the repository’s .git directory, and the file is marked executable.
4. Wait for Git to fire the hook: The next Git operation that touches the index — which happens continuously in any active repository — executes the hook payload as the Gitea OS service account.

Exploitation Requirement	Real-World Barrier	Context
Repository write access	Near-zero	Open registration on by default; attacker creates own repo and is its owner
Git ≥ 2.32 on the server	Near-zero	Git 2.32 released April 2021; present on virtually every current Linux distro
Writable, exec-capable /tmp	Low	Standard Linux; some hardened container runtimes may block noexec
Diffpatch API enabled	None	Enabled by default; no special configuration required

The Open-Registration Problem: “Requires Write Access” Can Mean Anyone on the Internet

The official vulnerability description reads “requires repository write access,” which might lead a security manager to conclude that the risk is limited to insider threats or external collaborators. That conclusion is incorrect.

Gitea ships with open user registration enabled by default. An attacker who can reach your Gitea login page — whether via a public IP, a misconfigured firewall rule, or an exposed internal service — can complete the entire exploit chain in under five minutes:

1. Navigate to the Gitea registration page and create a new account — no admin approval is needed
2. Create a new personal repository — ownership automatically grants write access
3. Execute the CVE-2026-60004 exploit against their own repository using the public PoC
4. Obtain a reverse shell or persistent backdoor running as the Gitea service account

If your Gitea instance is reachable from the internet and open registration has not been explicitly disabled, you effectively have an unauthenticated RCE vulnerability — CVSS 9.8 is not an overstatement. The public PoC lowers the skill threshold to near-zero. The clock is running.

What an Attacker Can Do After Code Execution

The Gitea service account — typically a dedicated OS user such as git or gitea — carries substantial implicit privilege on the host. Once an attacker achieves code execution in this context, the realistic post-exploitation sequence includes:

• Immediate credential harvest: Gitea’s app.ini configuration file contains the database password, the internal secret key used to sign session tokens, SMTP credentials, and any configured OAuth client secrets. An attacker reads it in seconds.
• Full repository dump: Every private repository on the server — proprietary source code, infrastructure-as-code Terraform/Ansible files, deployment scripts, API keys committed by developers — is readable by the Gitea service account.
• CI/CD pipeline poisoning: If Gitea is integrated with an Actions runner, Jenkins agent, Drone, or any other CI system, the attacker can modify pipeline YAML files or inject malicious build steps. Every subsequent build becomes a potential software supply-chain attack, silently shipping backdoored artefacts to production.
• Lateral movement to production: SSH deploy keys, cloud provider credentials (AWS access keys, GCP service account JSON), and internal API tokens stored in repositories provide stepping stones to production databases, cloud infrastructure, and connected SaaS platforms.

For organisations across India’s technology sector — where Gitea frequently serves as the authoritative source for both commercial software and digital-government infrastructure — a single compromised Gitea instance can cascade into a full organisational breach within hours. This threat directly parallels the TeamPCP supply-chain attack, where compromised developer tooling became the entry point for mass credential theft and ransomware deployment.

What You Should Do Right Now — The Expert Playbook

As a zero-trust practitioner with extensive experience securing enterprise networks in Delhi NCR and beyond, here is the action plan I would hand to any client with self-hosted Gitea today:

1. Upgrade to Gitea 1.27.1 immediately. This is the only complete remediation. The patch has been available since 27 July 2026 — there is no reason to run a vulnerable version. If a maintenance window is required, take the server offline until it can be patched; a brief planned outage is far preferable to an unplanned breach.
2. As an interim measure, disable open user registration. In app.ini, set DISABLE_REGISTRATION = true under the [service] section, or navigate to Site Administration → Configuration → Disable Self-Registration. This converts the vulnerability from practically-unauthenticated to requiring an existing account with write access — a meaningful reduction in attack surface while you prepare the upgrade.
3. Audit repository write permissions immediately. Remove write access from any user, bot, or integration that does not have a specific operational need for it. Apply the principle of least privilege across every repository on your server.
4. Review your Gitea access logs for exploit attempts. Search for multiple POST /api/v1/repos/*/diffpatch requests from the same user or IP within a short time window. Legitimate usage of this endpoint is uncommon; a pattern of rapid, repeated calls is a strong indicator of exploit activity.
5. Check all .git/hooks/ directories for unexpected files. Any executable file in a repository hook directory that you did not place there should be treated as an indicator of compromise and investigated immediately.
6. Place your Gitea server behind a ZTNA gateway or VPN. From a zero-trust architecture standpoint, an internal source-code management platform should never be directly internet-facing. Requiring authenticated network access before the Gitea login page is even reachable structurally eliminates the open-registration attack path. This is consistent with the same principles covered in our analysis of the GitLab authenticated RCE — git platforms need network-level protection, not just application-level controls.
7. Run the Gitea service account with minimal OS privileges. It should operate as a non-root user, ideally with a read-only filesystem mount for everything except the data directory. If the service account is currently running as root, that is an independent critical finding that requires urgent remediation.

Further technical details and the official security advisory can be found in the The Hacker News coverage and the official Gitea blog. The Gitea project maintains a security advisories page on GitHub where all CVE disclosures are published.

Frequently Asked Questions

Is Gitea Cloud (gitea.com) affected by CVE-2026-60004?

No. Gitea Cloud managed instances were automatically upgraded to version 1.27.1 on 27 July 2026, before the public security advisory was released. The risk is confined entirely to self-hosted Gitea deployments running any version from 1.17 through 1.27.0.

If I disable open registration, does that fully protect me?

It substantially raises the bar. An attacker would need an existing account with write access to at least one repository on your server — a genuine prerequisite. However, if any external contributors, contractors, or third-party integrations have write access, the risk is not eliminated. Upgrading to 1.27.1 is the only complete fix. Disabling open registration is a valuable interim control, not a substitute for patching.

My Git server version is older than 2.32 — am I safe?

The post-index-change hook mechanism that this exploit relies on was introduced in Git 2.32 (April 2021). If your server runs a Git version older than 2.32, this specific exploit path does not apply — but operating a five-year-old Git installation carries its own serious security risks, and upgrading Git should be on your immediate backlog regardless of this CVE.

How do I determine whether my server was already compromised before I patched?

Begin with these forensic checks: inspect .git/hooks/ directories across all repositories for unexpected executable files; review /etc/cron* and user crontabs for the Gitea service account; check for unfamiliar outbound network connections originating from the Gitea host; look for new SSH authorised keys in the service account’s home directory; and review app.ini for any configuration changes you did not make. If any of these checks raise a flag, treat the server as compromised and initiate a full incident-response process — do not simply patch and continue.

---

Ready to find out what an attacker would discover on your network before they do? Sanjay Seth is a Delhi NCR-based cybersecurity consultant specialising in zero-trust architecture, FortiGate security, and NOC/SOC operations. If your organisation runs self-hosted developer infrastructure — or any internet-facing service — a security assessment can identify your real exposure before the next public PoC drops. Get in touch for a consultation today.