Gitea CVE-2026-60004: diffpatch endpoint enables Git hook planting and RCE — actively exploited, now in the CISA KEV

TL;DR — 90 seconds

Affected?

Gitea instances running versions 1.17 through 1.27.0 with a reachable diffpatch API endpoint — practically any default installation in that version range, especially with open registration.

Risk?

CVSS 3.1: 9.8 (Critical) — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. An add/add collision while applying a patch lets an attacker plant a malicious Git hook (hooks/post-index-change) that runs with the Gitea service account's privileges — effectively unauthenticated remote code execution, since open registration lets an attacker create their own account.

Immediate action?

Update to Gitea 1.27.1 or newer. Also set DISABLE_REGISTRATION = true if open registration isn't needed.

Recommendation?

Patch immediately — CISA added the flaw to the KEV on Aug 25, 2026, with a remediation deadline of Aug 28, 2026 for US federal agencies. Active exploitation with a crypto-mining payload is documented.

Criticality?

critical — CVSS 9.8, actively exploited, in the CISA KEV.

What is the problem?

The /api/v1/repos/{owner}/{repo}/diffpatch endpoint exists to apply a patch against a repository for preview purposes, without actually committing it. To do so, Gitea applies the submitted patch internally against a bare clone of the repository.

If an attacker submits the same patch twice, applying it triggers a so-called "add/add" collision — a conflict where both patch versions try to create the same new file. This collision can be crafted so that an executable file ends up at the path hooks/post-index-change inside the repository — a Git hook that runs automatically whenever the index is updated. Because Gitea performs these index operations with its own service account's privileges, the next index update executes the attacker-planted code with the same privileges as the Gitea server process itself.

The twist: the CVSS vector lists PR:N (no privileges required) because Gitea instances in their default configuration allow open registration without email confirmation or administrator approval. An attacker therefore only needs to create their own account, create their own repository, and submit the crafted patches against the diffpatch endpoint there — existing write access to someone else's repository is not required.

Who is affected?

Check your installed version:

# via the web UI: Site Administration → Overview → Gitea version
# or via the API:
curl -s your-gitea-instance.example/api/v1/version

# or directly on the server (binary install):
gitea --version

Impact

Successful exploitation delivers code execution with the Gitea service account's privileges on the host system — not just inside the targeted repository. Because Gitea is often run as a central code and CI/CD source, the blast radius typically extends well beyond a single project: access to other repositories on the same instance (including private repos, if the service account has matching filesystem permissions), to stored CI/CD secrets and deploy keys, and potentially lateral movement into connected build and deployment infrastructure.

Attacks documented so far drop a crypto-miner dropper: a script clears relevant environment variables (LD_PRELOAD, LD_LIBRARY_PATH), kills competing high-load processes, fetches an architecture-specific payload, runs it, and then removes traces. The resulting mining load has consumed over 70% of server CPU capacity in observed cases — a comparatively "harmless" but highly visible form of abuse. Nothing about the vulnerability itself limits an attacker to crypto-mining, though; the same code execution just as easily enables targeted data theft or planting backdoors in hosted projects.

Mitigation / immediate steps

Operational decision block

• Act now if … your Gitea instance runs a version between 1.17 and 1.27.0 and the API endpoint is reachable — regardless of whether the instance is public or internal-only.
• Check with priority if … open registration is enabled and you don't know exactly who has registered in the past.
• Next regular window if … you've already updated to 1.27.1 or newer.

Step 1 — update to Gitea 1.27.1 or newer

# check current version
gitea --version

# Docker deployments: pull the current image and recreate the container
docker pull gitea/gitea:1.27.1
docker compose up -d gitea

# binary installs: get the official release from codeberg.org/gitea/gitea or
# gitea.com/gitea/gitea and follow the official upgrade guide
# (don't forget a database and repository backup before upgrading)

Step 2 — close open registration

# in app.ini, [service] section:
[service]
DISABLE_REGISTRATION = true

# alternatively, if registration is still needed:
REGISTER_EMAIL_CONFIRM = true
# and consider manual admin approval for new accounts

This hardening step doesn't close the flaw itself, but it removes the easiest path to an account for an opportunistic attacker — also useful as general hardening against future flaws of this kind.

Step 3 — review API exposure

# rule of thumb: don't expose Gitea instances with sensitive repositories
# unprotected to the public internet; restrict API access where possible to
# known network ranges or behind a VPN/zero-trust gateway

Detection / verification

Check repository hooks for unauthorized files

# on the Gitea server: scan all repository directories for suspicious
# post-index-change hooks
find /data/gitea-repositories -type f -name "post-index-change" -exec ls -la {} \;

# back up and manually review the contents of any hits before deleting
cat /path/to/repo.git/hooks/post-index-change

Check API logs for repeated diffpatch requests

# search Gitea access logs for unusually frequent calls from the same
# account against the diffpatch endpoint
grep "diffpatch" /var/log/gitea/access.log | awk '{print $1, $7}' | sort | uniq -c | sort -rn | head -20

Newly registered accounts with unusual behavior

A typical pattern: a freshly registered account immediately creates a repository and then goes dormant. Cross-check this via the admin UI (Site Administration → User Accounts, sorted by registration date) or via the API.

Unusual CPU load with no explainable build activity

# identify running processes with unusually high CPU load
top -b -n 1 | head -20

# specifically check the process tree of the Gitea service account
ps -u git -o pid,ppid,cmd,%cpu --sort=-%cpu | head -10

CISA and the cited sources name these four patterns — unauthorized files in the hooks/ directory, repeated diffpatch calls, register-then-dormant accounts, and unexplained CPU spikes — as concrete indicators of this campaign.

Operator guidance

Mid-market

Update to 1.27.1 immediately and close open registration — the CISA KEV listing and documented active exploitation justify an emergency update outside the regular maintenance window.

Enterprise / multi-repo operators

Beyond the update: check all repository directories for unauthorized post-index-change hooks, review the past few weeks of registration history for register-then-dormant patterns, and rotate CI/CD secrets and deploy keys if there's any indication of compromise. Gitea instances serving as the central source for build pipelines deserve particular attention here.

Government / regulated industries

US federal agencies (FCEB) had to remediate by Aug 28, 2026 per the CISA KEV entry. Even without a direct reporting obligation, this timeframe is a realistic benchmark for urgency at any organization with elevated protection needs that runs self-hosted Gitea instances.

Decision block

Act today if: a Gitea instance running versions 1.17–1.27.0 is in production, regardless of public or internal-only reachability. Monitoring is enough if: you've already updated to 1.27.1, disabled open registration, and found no anomalies in hooks, logs, or CPU load.

Conclusion

CVE-2026-60004 is a lesson in how an ostensibly harmless preview feature (patch preview without a commit) turns into a full RCE chain via a file-creation collision — and how much a convenient default setting like open registration can raise a flaw's practical exploitability. Gitea is often run precisely by teams that deliberately move away from larger SaaS platforms toward self-hosted solutions — that self-reliance explicitly includes applying security updates promptly. With a CVSS of 9.8, confirmed active exploitation, and a CISA KEV listing, there's no room for interpretation here: patch, harden registration, check repository hooks.

Sources

• The Hacker News — Critical Gitea RCE Actively Exploited as Reported Attack Drops Miner-Like Payload
• BleepingComputer — Over 8,300 Gitea servers vulnerable to code execution attacks (Aug 28, 2026)
• Zero Day Hub — Gitea RCE: CVE-2026-60004 Exploited in the Wild (Aug 26, 2026)
• GBHackers — Critical Gitea Flaw Lets Unauthenticated Attackers Read Server Files and Execute Code
• CISA — Known Exploited Vulnerabilities Catalog
• Gitea — official releases on GitHub