CISA added CVE-2026-60004, a critical code-injection flaw in the self-hosted Gitea source-code management platform, to its Known Exploited Vulnerabilities catalog on August 25 after researchers confirmed attackers are already using it in the wild. The vulnerability, rated 9.8 on the CVSS scale, lets a low-privileged user with repository write access plant an executable Git hook and run arbitrary shell commands as the Gitea service account. Federal civilian agencies have been given until August 28 to remediate, an unusually tight three-day window that signals the severity CISA has assigned to the flaw.
Context
Gitea is a widely deployed, lightweight alternative to GitHub and GitLab for organisations that prefer to run their own source-code management infrastructure rather than rely on a cloud provider. The flaw sits in Gitea’s diffpatch functionality: an attacker can submit a specially crafted patch that manipulates the diff-application process so that repository-controlled content is written out as a live Git hook — specifically a hooks/post-index-change script — rather than an ordinary tracked file. The next time that hook fires during a routine Git operation, it executes with the privileges of the Gitea process itself.
The practical severity comes from how little access is required to trigger it. Any account with write access to a single repository can exploit the bug, and Gitea instances that leave open self-registration enabled — a common default in smaller engineering teams — allow an external attacker to obtain that access simply by signing up. Researchers reported that an automated scanner registered its own account, created a throwaway repository, and walked through the full exploit chain without further interaction, on instances still running the vulnerable release with no email confirmation or CAPTCHA gating registration.
The bug affects every Gitea release from version 1.17 onward. Gitea’s maintainers shipped a fix in version 1.27.1 in late July, crediting security researcher Shai Rod (NightRang3r) for the report. The August 25 KEV addition confirms that a meaningful population of instances remained unpatched a month later.
What’s Been Observed
Independent researchers and CISA both describe the currently observed activity as opportunistic rather than targeted. At least one confirmed case involved an attacker using the flaw to drop a cryptocurrency-miner-style payload after gaining shell access — consistent with automated, internet-wide scanning for exposed, outdated Gitea instances rather than a bespoke campaign against a specific organisation. No attribution to a named threat actor or group has been made public. Security teams should nonetheless treat this as a live, exploited condition: opportunistic access-for-sale operators frequently resell footholds gained this way to more capable actors, including ransomware affiliates, once initial compromise is established.
What It Means for Affected Sectors
Gitea’s user base skews toward engineering teams that want infrastructure they control directly — a profile common in critical infrastructure operators, financial services firms, and telecom/communications providers running internal tooling, automation scripts, or OT-adjacent configuration management outside of hyperscaler cloud environments. A compromised Gitea instance is rarely the end goal; it is typically a pivot point into CI/CD pipelines, deployment credentials, and internal network segments the source-control server can reach. Organisations in these sectors that self-host developer tooling for internal automation should treat any internet-facing Gitea deployment as a priority asset regardless of its perceived operational unimportance.
Recommended Actions
- Patch immediately. Upgrade all Gitea instances to version 1.27.1 or later. Federal agencies face an August 28 deadline under CISA’s KEV mandate; private-sector organisations should treat this as equally urgent given confirmed in-the-wild exploitation.
- Disable open self-registration on any Gitea instance that does not require it, and enable CAPTCHA/email confirmation where registration must remain open.
- Audit repository hooks. Check for unexpected
hooks/post-index-changescripts or other unfamiliar hook files across all hosted repositories — this is the primary artifact of exploitation. - Review recent account creation and repository activity logs for anomalous new accounts followed immediately by patch submissions or repository creation, a pattern consistent with automated exploitation.
- Inventory internet-facing self-hosted developer tooling generally; Gitea, Gitea forks, and similar lightweight Git servers are frequently deployed by individual teams without central IT visibility, making them a recurring blind spot in vulnerability management programs.