Infrastructure · 26 Aug 2026 · Rob Nidschelm

Gitea Patched the Hook. CISA Says Attackers Are Using It.

Updated 29 August 2026: Shadowserver measured 8,393 IP addresses exposing Gitea instances vulnerable to CVE-2026-60004 on 27 August. The largest concentrations were in China, Germany and the United States.

Update: More than 8,300 vulnerable Gitea servers were still visible

This is exposure measurement, not a count of compromised servers. It nevertheless shows that thousands of reachable instances remained vulnerable after CISA added the flaw to the Known Exploited Vulnerabilities catalogue. The operational conclusion is unchanged but more urgent: administrators should upgrade, rotate secrets available to Gitea and its runners if compromise is suspected, and review hook changes and unexpected command execution.

• Shadowserver exposure measurement, published 28 August 2026 at 11:54 UTC.
• Shadowserver Gitea exposure dashboard.
• BleepingComputer independent reporting, published 28 August 2026 at 08:58. The page did not expose a timezone.

A critical Gitea remote-code-execution vulnerability has moved from published proof of concept to confirmed exploitation. CISA added the flaw to its Known Exploited Vulnerabilities catalogue on 25 August, making version verification and incident review urgent for every exposed self-hosted instance.

The exploited issue is CVE-2026-60004. It turns ordinary repository write access into shell-command execution as the operating-system account that runs Gitea. The project fixed it in Gitea 1.27.1, released in July. CISA has not identified the attackers, targets, scale or observed payloads behind the exploitation.

A code patch became a live Git hook

Gitea’s diffpatch API applies user-controlled patches inside a shared bare temporary clone. The public advisory explains that submitting the same crafted patch twice creates an add/add collision. Git’s three-way fallback can then check an indexed path out even though the operation uses --cached.

That detail is decisive. In a bare clone, the repository root is $GIT_DIR. An executable file written as hooks/post-index-change is not merely repository content. It becomes an active Git hook. Git invokes it while updating the index, and the attacker’s commands run as the Gitea service account.

The proof of concept does not require a reverse shell or any other outbound connection. It can store command output in Git objects, create a branch containing the result, and retrieve that branch through authenticated smart HTTP. A normal-looking API response is therefore not evidence that the hook did not execute.

Write access is required, but open registration can provide it

The core prerequisite for CVE-2026-60004 is the ability to write to a repository. On a tightly controlled private instance, that limits the initial attacker pool to existing users or compromised accounts.

On an internet-facing instance with open registration and permission for new users to create repositories, the boundary is much weaker. A visitor can register a normal account, create a repository and obtain the access needed for the exploit path. Open registration is required only for that no-prior-credentials route.

The published exploit also assumes Git 2.32 or newer, an enabled diffpatch route, and a writable and executable temporary filesystem. Those conditions can help triage exposure, but they should not replace patching.

Versions 1.17 through 1.27.0 are affected

The Gitea security advisory lists versions from 1.17 up to, but not including, 1.27.1 as affected. Version 1.27.1 is the first fixed release. Administrators should upgrade to 1.27.1 or later, including the current maintenance release available for their deployment channel.

CISA gave US federal civilian agencies until 28 August 2026 to remediate the flaw. That deadline is a compliance boundary, not a safe waiting period. Any vulnerable internet-facing instance should be treated as an immediate patch-and-hunt case.

The same release fixed a separate unauthenticated file-read flaw

Gitea 1.27.1 also repaired CVE-2026-59774, a separate critical vulnerability in the Org-mode markup renderer. An anonymous attacker can submit a #+INCLUDE directive to the markup endpoint of a suitable public repository and read files accessible to the Gitea service account.

The affected range is Gitea 1.22.1 through 1.27.0. No repository write permission is required. A normal public repository with its code unit enabled is enough to expose the vulnerable route.

The advisory describes a path from file read to command execution by extracting Gitea’s INTERNAL_TOKEN from app.ini and using internal application capabilities to install a Git hook. That makes the issue operationally significant even though the initial primitive is file disclosure.

The evidence status is different from the exploited hook vulnerability. A public advisory, exploit details and a Nuclei detection template exist for CVE-2026-59774, but CISA has not added it to KEV and the vendor has not confirmed malicious exploitation. Coverage of one flaw must not be mistaken for coverage of the other.

What defenders should do now

• Upgrade every Gitea instance below 1.27.1, including internal systems that may be reachable through VPNs, development networks or compromised build agents.
• Identify instances with open registration, automatic repository creation, the diffpatch API and public repositories.
• Review newly created users and repositories, especially shortly before unexplained server-side process execution.
• Search application, reverse-proxy and API logs for repeated requests to /diffpatch and unusual markup requests containing Org-mode include directives.
• Inspect Gitea temporary directories and repository hook paths for unexpected executable files.
• Review child processes launched by the Gitea service account and investigate unexpected shell, downloader or scripting activity.
• Assume secrets readable by the Gitea account may be exposed after suspected compromise. Rotate application tokens, database credentials, OAuth secrets and integration credentials as appropriate.
• Check mounted repositories, runners and connected CI/CD systems for follow-on access.

Why KEV changes the response

The vulnerability was already critical when Gitea published the advisory and working proof of concept. KEV inclusion adds a different fact: exploitation is no longer hypothetical. It does not reveal how widespread the attacks are, but it removes the option of treating the issue as ordinary patch-cycle work.

For self-hosted development platforms, the blast radius extends beyond the web application. The Gitea service account often has access to source repositories, database credentials, integration tokens and build-system connections. A Git-hook primitive can therefore become a supply-chain incident even when the initial foothold is a low-privilege repository user.

Sources

• CISA KEV addition, published 25 August 2026, publication time not provided.
• Gitea advisory GHSA-rcr6-4jqh-j84m, published 28 July 2026, publication time not provided.
• Gitea advisory GHSA-6v53-hr58-556r, published 2 August 2026, publication time not provided.
• Gitea 1.27.1 release announcement, published 27 July 2026, publication time not provided.
• SecurityWeek independent reporting, published 26 August 2026 at 01:17 ET, 07:17 CEST.