Skip to content
feed: live
>_0dayNews
gitea
● Breaking

CISA: Gitea RCE Now Exploited, Miner Payloads Confirmed

CISA has added a critical Gitea code injection flaw to the KEV catalog as attackers drop cryptominer-like payloads on unpatched self-hosted instances. Patch to version 1.27.1 now.

CISA: Gitea RCE Now Exploited, Miner Payloads Confirmed
Image: AI-generated — no human photographer / 0dayNews AI Cover · Generated on-site infrastructure — no external license
fuseMarisol "Fuse" Delgado·Published ·2 min read

CISA added a critical remote code execution flaw in Gitea to its Known Exploited Vulnerabilities catalog on Tuesday, confirming what multiple security outlets had already started flagging: attackers are hitting unpatched self-hosted Gitea instances and dropping cryptominer-like payloads.

The vulnerability — identified by CISA as CVE-2026-60004 with a CVSS score of 9.8 — is a code injection flaw in Gitea’s diffpatch API endpoint. An attacker with write access to any repository on the target instance can send a specially crafted patch that plants an executable Git hook, then trigger it to run shell commands as the Gitea service account. The GitHub Security Advisory describes this as a repository write-access-to-RCE chain.

Gitea developers patched this in version 1.27.1, released in late July. The Hacker News confirmed Tuesday that real-world attacks are dropping miner-like payloads on compromised servers — consistent with opportunistic threat actors farming compute on anything they can reach.

Who’s exposed

If your Gitea instance allows external contributors — open-source projects, contractor access, or any setup where accounts outside your organization can push code — consider that route live until you’ve patched. Internal-only instances with no external write access are at lower immediate risk, but the service account execution means post-patch cleanup matters too: check for unauthorized Git hooks in existing repositories if you’re on any version before 1.27.1.

What to do

Patch priority is straightforward:

  1. Upgrade to Gitea 1.27.1 immediately. No workaround substitutes for the fix. Download from the official release page.
  2. Audit existing repositories for injected hooks. Check .git/hooks/ directories for unexpected executables, particularly post-receive, pre-receive, and update hooks.
  3. Review service account permissions. If your Gitea service account runs with elevated OS privileges, this is the time to scope it down — the exploit runs as that account.
  4. Federal agencies operating Gitea have an enforceable patching deadline under BOD 22-01. Check your CISA KEV compliance window.

The KEV listing follows SecurityWeek’s coverage and confirms what the July patch advisory implied — this class of API-level hook injection was a realistic attack surface from the moment it was disclosed.

Context

We covered the original Gitea 1.27.1 patch when it dropped in July. The exploit path was clear then; the gap between patch and active exploitation — less than a month — is a reminder that public Git tooling is a high-value target for opportunistic attackers who automate scanning for version strings.

A prior Gitea Docker authentication bypass (CSA-1264) showed the same pattern: a disclosed flaw gets active exploitation relatively quickly once it’s understood. Gitea’s self-hosted nature means patch adoption is entirely on instance owners — there’s no cloud-side kill switch.

If you’re running Gitea and you’re not on 1.27.1, you’re the target.

Found this useful? Share it.