TL;DR
- what: CISA confirmed active exploitation of CVE-2026-60004, a CVSS 9.8 code injection flaw in Gitea's diffpatch API that plants an executable Git hook and runs shell commands as the Gitea service account.
- impact: Any user who can write to a repository gets remote code execution on the Gitea host, and with default open registration that user can be a stranger who registered an account minutes earlier; one reported victim had a miner-like dropper burn more than 70 percent of their VPS CPU until the hosting provider throttled them.
- fix: Upgrade to Gitea 1.27.1, then set DISABLE_REGISTRATION to true, REQUIRE_SIGNIN_VIEW to true, and audit every repository for hooks planted before the patch.
- who: Every organization running a self-hosted Gitea instance from 1.17 through 1.27.0, especially internet-facing instances with open registration, plus U.S. federal civilian agencies bound by the KEV deadline.
CISA added CVE-2026-60004 to its Known Exploited Vulnerabilities catalog on Tuesday and gave federal civilian agencies until August 28, 2026 to remediate. The flaw carries a CVSS score of 9.8 and it converts any account with write access to a repository into shell access on the Gitea host. On instances that kept the shipped default of open registration, that account costs an attacker nothing more than filling out a signup form.
What the vulnerability actually does
Gitea's diffpatch API endpoint takes a patch and applies it to repository content. The endpoint does not prevent that patch from writing into the repository's hooks directory. An attacker submits a patch that installs an executable Git hook built entirely from repository controlled content, then triggers it through ordinary Git activity. The hook executes as the Gitea OS user. Gitea's own advisory, published last month, described it as abusing diffpatch to install and execute a Git hook from repository controlled content. Security researcher Shai rod, who works under the handle NightRang3r, reported the issue.
Every Gitea release from 1.17 onward is affected. Version 1.27.1 is the fix. That is roughly eight years of releases, which means a lot of long running internal instances that nobody has touched since they were stood up are sitting in the affected range right now.
⚠️ Authentication is not the mitigation it looks like — The vulnerable API call requires an authenticated user with repository write permission. That requirement collapses because Gitea allows self registration by default. An unauthenticated visitor registers an account, creates a repository, and now holds write permission on content they fully control. No stolen credentials, no phishing, no lateral movement required.
The configuration that turns a hard bug into an easy one
A developer writing under the handle Causelof published an incident analysis on Habr last week after their own Gitea instance was hit. They pointed at four configuration values as the reason the attack succeeded, and all four are common on instances that were set up for convenience rather than exposure to the open internet:
- DISABLE_REGISTRATION = false, meaning anyone can create their own account rather than requiring an admin to provision it
- REGISTER_EMAIL_CONFIRM = false, meaning registration does not even require a working mailbox
- ENABLE_OPENID_SIGNUP = true, adding a second self service path to an account
- REQUIRE_SIGNIN_VIEW = false, meaning pages and API surface are reachable before any login
Worth noting for anyone who assumes SSH exposure is the risk: in the reported incident SSH was not reachable from the internet at all. The attack came in over HTTPS. Blocking port 22 at the perimeter does nothing here, because the vulnerable path is the web API you deliberately published.
What the reported payload did
The victim found out the way a lot of cryptojacking victims find out. Their hosting provider, HOSTKEY, emailed to say the virtual server had been running above 70 percent processor utilization for an extended period in violation of the terms of service, and then throttled the available CPU. Working backward from that notice led to the compromise. The dropper script that ran before the final payload followed a recognizable sequence:
- Clear LD_PRELOAD and LD_LIBRARY_PATH to shed any preloaded instrumentation
- Enumerate processes with high CPU usage
- Attempt to kill competing processes, the standard behavior of a miner clearing rival miners off the box
- Fetch an architecture specific payload
- Write the payload to disk and execute it
- Delete the file from disk after execution
The next stage payload was never analyzed. The reporting developer said plainly that they have no confirmed information on the mining pool, wallet, miner family, or operator. So treat cryptomining as the strong inference it is, supported by the CPU profile and the competitor killing behavior, and not as a confirmed attribution. The kill competitors step and the delete after execution step also matter defensively: the binary may not be on disk when you go looking for it.
What CISA did not say
The KEV entry contains no exploitation details, no indicators, and no actor attribution. It is not clear whether the catalog addition was driven by this specific Habr incident or by separate evidence of unpatched Gitea servers being hit inside the United States. That gap does not change what you should do. A KEV listing means exploitation is confirmed somewhere, and the operational answer is the same either way.
Patching closes the door, it does not evict anyone
Upgrading to 1.27.1 stops new hooks from being planted through diffpatch. It does not remove a hook that was already written, and a planted hook survives the upgrade intact, waiting for the next push event. If your instance was internet reachable with open registration before you patched, assume the window mattered and go look. Priority checks:
- Inspect the hooks directory of every repository for non default or recently modified hook scripts, particularly pre-receive, post-receive, and update
- Grep hook contents for curl, wget, base64, and any outbound host you do not recognize
- Review accounts registered and repositories created in the window between the 1.27.1 release and your upgrade, then look hard at any account with a single throwaway repository
- Check for child processes spawned by the Gitea service account and for sustained CPU consumption on the host
- Review outbound connections from the Gitea host, including common mining pool ports such as 3333, 4444, 5555, and 14444
- Rotate anything the Gitea service account could read, including deploy keys, CI tokens, and webhook secrets
Configuration baseline after the upgrade — Set DISABLE_REGISTRATION to true so only admins provision accounts, set REQUIRE_SIGNIN_VIEW to true, disable ENABLE_OPENID_SIGNUP unless you actively use it, and enable REGISTER_EMAIL_CONFIRM if you must keep self service. Run the Gitea service as an unprivileged user with no access to the Docker socket, and put the instance behind SSO or a VPN if it does not need to be public.
Bottom line
This is a low effort, high yield target: a 9.8 rated bug, an eight year affected range, a default configuration that hands the attacker the prerequisite, and confirmed exploitation in the wild. The federal deadline of August 28, 2026 is a reasonable benchmark for everyone else too. Upgrade to 1.27.1, close registration, then hunt for the hooks.
Originally published on RedEye Threat Intelligence.
Top comments (0)