CVE-2026-60004: Gitea Unauthenticated RCE Under Active Exploitation — Detection, Hunting, and Remediation Guide

On Tuesday, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) issued an urgent warning that threat actors are actively exploiting CVE-2026-60004, a critical unauthenticated remote code execution vulnerability in Gitea, the widely deployed self-hosted Git service. The flaw carries a CVSS score of 9.8 and allows an attacker with ordinary write access to a repository to execute arbitrary shell commands on the underlying host. Confirmed in-the-wild exploitation is delivering miner-like malicious payloads — a classic post-compromise monetization pattern that signals the vulnerability is being mass-scanned and weaponized by opportunistic actors, not just targeted intrusions.

If you operate Gitea — internally for development teams, or exposed to the internet for open-source collaboration — treat this as an incident-in-progress, not a patching ticket. A 9.8-severity RCE on a source code management platform is a supply-chain-grade exposure: beyond the host itself, attackers gain a foothold inside your CI/CD pipeline, your source code, your secrets, and every downstream system that consumes your repositories. Cryptominers are often just the first-stage payload dropped by automated tooling; the same access routinely gets resold or re-leveraged for deeper compromise.

Technical Analysis

Vulnerability Overview

How the Attack Works — Defender's View

The exploitation chain observed in this campaign follows a pattern we have seen repeatedly against developer infrastructure:

1. Access acquisition. The attacker obtains repository write access. On many Gitea deployments this is trivial — open self-registration is a common default on internet-facing instances, and CVE-2026-60004 lowers the bar further by enabling code execution from that low-privilege starting point.
2. Code execution trigger. The vulnerability allows repository-level write operations to be abused to execute arbitrary shell commands as the operating system user running the Gitea service (commonly the git user). From a detection standpoint, the pivotal observable is the Gitea server process spawning shell interpreters and system utilities it has no business spawning — sh, bash, curl, wget, chmod, and base64 decode chains.
3. Payload retrieval and execution. Post-exploitation, the attacker pulls a second-stage payload from attacker-controlled infrastructure over HTTP/HTTPS, writes it to a world-writable location such as /tmp, /dev/shm, or /var/tmp, marks it executable, and launches it.
4. Miner deployment and persistence. The observed payloads behave like cryptominers: high sustained CPU consumption, outbound connections to mining pool infrastructure (commonly over Stratum protocol ports such as 3333, 5555, 7777, or 14444), process names masquerading as legitimate kernel threads or system services (e.g., kdevtmpfsi-style naming), and persistence via cron entries under the git or service account.

Why Miners Still Matter

Do not dismiss this as "just a miner." In our IR casework, miner deployment on a server exposed via RCE is consistently one of three things: automated spray-and-pray monetization, a resource-hijacking decoy while a second operator stages real objectives, or a beachhead later sold to access brokers. The same code execution path that drops XMRig today drops a credential harvester, a CI/CD secret stealer, or ransomware tomorrow. Source code platforms are also uniquely sensitive: an attacker with code execution on your Gitea host can poison repositories, tamper with release artifacts, and pivot into your build infrastructure.

Detection & Response

The detections below target the two highest-fidelity observables from this campaign: (1) the Gitea process spawning shell/command interpreters, and (2) miner behavior and persistence on the host. Tune thresholds to your baseline — CI-heavy environments where Gitea legitimately triggers build tooling will need tighter scoping on parent process and user context.

Sigma Rules

---
title: Gitea Server Process Spawning Shell or Download Utility
id: 3f8a2c41-9b6d-4e17-a2c8-7d1e5f0a9b3c
status: experimental
description: Detects the Gitea service process spawning shell interpreters, download utilities, or encoding tools. Consistent with CVE-2026-60004 exploitation where repository write access is abused to execute arbitrary shell commands as the git service account.
references:
  - https://thehackernews.com/2026/08/critical-gitea-rce-actively-exploited.html
  - https://attack.mitre.org/techniques/T1059/004/
author: Security Arsenal
date: 2026/08/05
tags:
  - attack.execution
  - attack.t1059.004
  - attack.t1190
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/gitea'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/curl'
      - '/wget'
      - '/python'
      - '/python3'
      - '/perl'
      - '/base64'
      - '/nc'
      - '/ncat'
  condition: selection_parent and selection_child
falsepositives:
  - Gitea instances with repository hooks or custom automation that legitimately invoke scripts (review hook content; unexpected interpreters or network utilities are the anomaly)
level: high
---
title: Cryptominer Deployment Artifacts Following Web Service Compromise
id: 6b1d4e82-2a7f-4c39-b5d1-8e3f0c6a2d94
status: experimental
description: Detects common cryptominer execution artifacts observed in the CVE-2026-60004 Gitea campaign, including execution from world-writable paths and miner-typical process naming that masquerades as kernel threads.
references:
  - https://thehackernews.com/2026/08/critical-gitea-rce-actively-exploited.html
  - https://attack.mitre.org/techniques/T1496/
author: Security Arsenal
date: 2026/08/05
tags:
  - attack.impact
  - attack.t1496
  - attack.t1036
logsource:
  category: process_creation
  product: linux
detection:
  selection_path:
    Image|startswith:
      - '/tmp/'
      - '/dev/shm/'
      - '/var/tmp/'
  selection_name:
    Image|contains:
      - 'xmrig'
      - 'kdevtmpfsi'
      - 'kinsing'
      - 'minerd'
      - 'cpuminer'
      - 'nanominer'
  condition: 1 of selection_*
falsepositives:
  - Rare; legitimate software should not execute from /tmp or /dev/shm in production environments
level: high
---
title: Cron Persistence Created by Git or Web Service Account
id: 9c4e7a15-3d8b-4f26-a1c7-5b2e9d0f8a63
status: experimental
description: Detects modification of cron files by the git service account or unexpected users, a persistence technique used by miner payloads dropped via CVE-2026-60004 to survive reboots and re-establish execution.
references:
  - https://thehackernews.com/2026/08/critical-gitea-rce-actively-exploited.html
  - https://attack.mitre.org/techniques/T1053/003/
author: Security Arsenal
date: 2026/08/05
tags:
  - attack.persistence
  - attack.t1053.003
logsource:
  category: file_event
  product: linux
detection:
  selection:
    TargetFilename|startswith:
      - '/etc/cron'
      - '/var/spool/cron'
      - '/var/spool/cron/crontabs'
  filter_root:
    User: 'root'
  condition: selection and not filter_root
falsepositives:
  - Service accounts legitimately managing their own crontabs (rare on Gitea hosts); investigate any entry referencing /tmp, /dev/shm, curl, wget, or base64
level: medium

KQL (Microsoft Sentinel / Defender)

This query assumes Linux Syslog/CEF ingestion from your Gitea hosts into Sentinel. It hunts the full campaign chain: Gitea-spawned shells, miner execution from temp paths, and Stratum-pool egress.

// Hunt: CVE-2026-60004 Gitea exploitation and miner payload staging
// Scope: Linux hosts ingested via Syslog / CEF / Defender for Endpoint
let lookback = 7d;
let GiteaShellSpawn = Syslog
| where TimeGenerated > ago(lookback)
| where ProcessName =~ "gitea"
| where SyslogMessage has_any ("/bin/sh", "/bin/bash", "curl", "wget", "base64", "chmod +x")
| project TimeGenerated, Computer, ProcessName, SyslogMessage, HostIP;
let MinerExecution = DeviceProcessEvents
| where TimeGenerated > ago(lookback)
| where FolderPath has_any ("/tmp/", "/dev/shm/", "/var/tmp/")
   or FileName has_any ("xmrig", "kdevtmpfsi", "kinsing", "minerd", "nanominer")
| project TimeGenerated, DeviceName, FileName, FolderPath, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine;
let StratumEgress = DeviceNetworkEvents
| where TimeGenerated > ago(lookback)
| where RemotePort in (3333, 5555, 7777, 14444, 45700)
| where InitiatingProcessFolderPath has_any ("/tmp/", "/dev/shm/", "/var/tmp/")
   or InitiatingProcessFileName has_any ("xmrig", "kdevtmpfsi", "kinsing", "minerd")
| project TimeGenerated, DeviceName, RemoteIP, RemoteUrl, RemotePort, InitiatingProcessFileName, InitiatingProcessCommandLine;
union GiteaShellSpawn, MinerExecution, StratumEgress
| sort by TimeGenerated desc

Velociraptor VQL

Use this artifact across your Linux fleet (via the Velociraptor Linux collector) to sweep for the post-exploitation footprint: miner processes running from volatile paths and their network connections.

-- Hunt: Miner-like payloads staged by CVE-2026-60004 Gitea exploitation
-- Identifies processes executing from volatile/world-writable paths,
-- miner-typical names, and their active network connections.

SELECT Pid,
       Name,
       Exe,
       CommandLine,
       Username,
       CreateTime
FROM pslist()
WHERE Exe =~ '^/(tmp|dev/shm|var/tmp)/'
   OR Name =~ '(?i)(xmrig|kdevtmpfsi|kinsing|minerd|nanominer|cpuminer)'
   OR CommandLine =~ '(?i)(stratum\+tcp|stratum\+ssl|xmrig|monero|nanopool|supportxmr|minexmr)'

-- Follow-on: enumerate cron persistence writable by the gitea service account
-- and flag entries referencing volatile paths or download utilities.

SELECT FullPath,
       Mtime,
       read_file(filename=FullPath) AS CronContent
FROM glob(globs='/var/spool/cron/**,/var/spool/cron/crontabs/**,/etc/cron.d/*,/etc/crontab')
WHERE CronContent =~ '(?i)(/tmp/|/dev/shm/|curl |wget |base64|xmrig|stratum)'

Triage & Hardening Script

Run the following on every Gitea host. It collects triage evidence first (so you preserve artifacts if IR is needed) and then validates patch posture.

#!/usr/bin/env bash
# CVE-2026-60004 Gitea triage & verification script
# Run as root on each Gitea host. Review output before any remediation action.

echo "=== [1] Gitea version (confirm against vendor advisory patched versions) ==="
sudo -u git /usr/local/bin/gitea --version 2>/dev/null || /usr/local/bin/gitea --version 2>/dev/null || echo "Adjust path to gitea binary"

echo "=== [2] Suspicious child processes of gitea (shells, downloaders, encoders) ==="
GITEA_PIDS=$(pgrep -f '/gitea' | tr '\n' ',')
ps -eo pid,ppid,user,comm,args --forest | grep -Ei 'gitea|sh$|bash|curl|wget|base64|nc ' | grep -v grep

echo "=== [3] Executables in volatile paths ==="
find /tmp /dev/shm /var/tmp -type f -executable -mtime -14 -ls 2>/dev/null

echo "=== [4] Known miner processes ==="
ps -eo pid,user,comm,args | grep -Ei 'xmrig|kdevtmpfsi|kinsing|minerd|nanominer|cpuminer|stratum' | grep -v grep

echo "=== [5] High-CPU processes (miner symptom) ==="
ps -eo pid,ppid,user,%cpu,comm --sort=-%cpu | head -15

echo "=== [6] Outbound connections to common mining pool ports ==="
ss -tunp 2>/dev/null | grep -E ':(3333|5555|7777|14444|45700)\b' || echo "No stratum-port connections observed"

echo "=== [7] Cron persistence (all users, flag volatile-path/download references) ==="
for u in $(cut -d: -f1 /etc/passwd); do crontab -u "$u" -l 2>/dev/null | sed "s/^/[user:$u] /"; done
ls -la /etc/cron.d/ /var/spool/cron/ /var/spool/cron/crontabs/ 2>/dev/null
grep -rEi '(/tmp/|/dev/shm/|curl|wget|base64|stratum|xmrig)' /etc/cron* /var/spool/cron/ 2>/dev/null

echo "=== [8] Gitea admin/repo integrity spot-check ==="
ls -lat /var/lib/gitea/data/gitea-repositories/ 2>/dev/null | head -10
echo "Review Gitea admin panel: unexpected user registrations, new repos, modified hooks"
find /var/lib/gitea -name 'post-receive' -newer /etc/hostname -ls 2>/dev/null

echo "=== TRIAGE COMPLETE — preserve output, then patch/upgrade Gitea per vendor advisory ==="

Remediation

Given confirmed active exploitation and CISA's warning, execute the following in order of priority:

1. Patch immediately. Upgrade Gitea to the latest patched release published by the Gitea project addressing CVE-2026-60004. Consult the official advisories at https://github.com/go-gitea/gitea/security/advisories and the release notes at https://github.com/go-gitea/gitea/releases. Docker deployments should pull the updated image tag and rebuild containers rather than patching in place. Do not rely on version strings alone — verify the deployed binary/image digest against the vendor's published artifacts.
2. If you cannot patch today, reduce exposure. Take internet-facing Gitea instances behind VPN or IP allowlisting, disable open self-registration, and disable new repository creation for unauthenticated/low-privilege users. These are mitigations, not fixes — the exploitation path only requires repository write access, so any authenticated low-trust user remains a risk until patched.
3. Hunt before you patch. Patching first destroys evidence. If the instance was internet-reachable during the exploitation window, run the triage script and queries above, image the host if any indicator fires, and treat positive findings as a full incident: the attacker had code execution as the service account, which means any secret readable by that account (deploy keys, tokens in app.ini, CI credentials, database contents) must be considered compromised.
4. Rotate credentials. Rotate the Gitea database password, any tokens/API keys stored on the host, deploy keys, and integration secrets (webhook secrets, OAuth client secrets) on any host showing evidence of exploitation.
5. Audit repositories and hooks. Review recently created/modified repositories, server-side hooks, and newly registered user accounts. Attackers with repository write access may have planted malicious content that survives the patch.
6. Egress filtering. Block outbound connections from Gitea hosts to non-essential destinations, particularly Stratum mining ports (3333, 5555, 7777, 14444) and known pool domains. A Git server has very narrow legitimate egress: upstream Git remotes, package mirrors, and your package/update infrastructure.
7. Follow CISA direction. With CISA having publicly flagged active exploitation, federal civilian agencies are subject to remediation deadlines under Binding Operational Directive 22-01; private-sector organizations should adopt the same urgency standard. This is exactly the class of flaw — trivially reachable, 9.8 severity, on developer infrastructure — that supply-chain attackers prize.

Longer-Term Hardening

• Run the Gitea service under a dedicated, minimally privileged account with no sudo rights and a locked-down home directory.
• Deploy EDR on Git/CI infrastructure — these hosts are historically underserved by endpoint coverage because they're "dev systems." This campaign is why that assumption fails.
• Alert on the Gitea process tree as a standing detection (the first Sigma rule above is worth keeping permanently, tuned for your environment).
• Treat source code management platforms as Tier 0 assets in your asset inventory and patch SLA — ahead of general-purpose servers.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub