CVE-2026-60004: Gitea Code Injection Exploitation — KEV Detection and Remediation Guide

On August 25, 2026, CISA added CVE-2026-60004 — a code injection vulnerability in Gitea, the widely deployed self-hosted Git service — to its Known Exploited Vulnerabilities (KEV) Catalog based on confirmed evidence of active exploitation in the wild. Under Binding Operational Directive (BOD) 26-04, Federal Civilian Executive Branch agencies are mandated to remediate KEV-listed vulnerabilities on an accelerated timeline. But if you think this is a federal-only problem, you're wrong. Gitea instances hold source code, CI/CD secrets, deploy keys, and developer credentials. A compromised Gitea server is a supply-chain beachhead, and every organization self-hosting Gitea — on-premises or in the cloud — should treat this as an active incident, not a patching ticket.

In our IR practice, source code management (SCM) platforms are consistently among the highest-value targets we see in post-compromise forensics. Adversaries don't just want your repos — they want the pipeline tokens, signing keys, and webhooks that turn read access into production access. This is exactly the class of vulnerability that gets weaponized fast.

Technical Analysis

What's affected

CVE-2026-60004 is a code injection vulnerability in Gitea, the lightweight, Go-based self-hosted Git platform used by hundreds of thousands of organizations worldwide — from small dev teams running it on a VPS to enterprises running large internal instances. Gitea deployments commonly expose:

• Web UI / API on TCP 3000 (default), frequently proxied behind nginx/Apache on 80/443
• SSH service for Git operations (built-in server on port 2222, or delegated to system OpenSSH on 22)
• A service account (typically git) with broad read/write access to repositories, webhooks, and configured CI/CD integrations

Code injection flaws in this class are a frequent exploitation pathway precisely because they convert an application-layer weakness into server-side command execution — giving the attacker a foothold on the host itself, not just the application. Depending on where the injection point sits in the request-handling path, exploitation may be possible with low privileges (an authenticated low-level user) or, in the worst configurations, pre-authentication against an internet-exposed instance. CISA's KEV listing is the authoritative signal: this is being exploited now, by real actors, against real targets.

Exploitation status

• Active exploitation: CONFIRMED — CISA KEV inclusion requires evidence of exploitation in the wild.
• KEV Catalog entry: CVE-2026-60004, added 2026-08-25.
• Remediation obligation: BOD 26-04 requires FCEB agencies to remediate KEV-listed CVEs within the directive's mandated window. Private-sector organizations should adopt the same urgency — KEV listing correlates strongly with widespread scanning and follow-on exploitation within days of disclosure.

Why this is a supply-chain event waiting to happen

The attack chain we counsel clients to model for an exploited SCM platform:

1. Initial access: Attacker exploits CVE-2026-60004 against the Gitea web application, achieving command execution in the context of the Gitea process (typically the git user).
2. Discovery: The attacker reads Gitea's app.ini (database credentials), enumerates repositories, and pulls deploy keys, webhook secrets, and any credentials committed to code.
3. Lateral movement / persistence: Stolen SSH keys and CI/CD tokens are replayed against build servers, artifact registries, and production infrastructure. Attackers may also inject malicious commits or tamper with release artifacts — a classic software supply-chain pivot.
4. Secondary payload deployment: With shell-level access on the Gitea host, expect web shells, reverse shells, and persistence via systemd units, cron, or the Gitea user's .ssh/authorized_keys.

Your detection strategy should therefore focus on two layers: (1) the Gitea process doing things it never legitimately does — spawning shells, writing to unexpected paths, making outbound connections — and (2) post-exploitation artifacts on the host.

Detection & Response

The detections below target the most reliable behavioral signals of exploitation: the gitea process (or its parent service account) spawning command interpreters and system utilities, suspicious file artifacts in Gitea's working directories, and anomalous network activity from the Gitea host. These are derived from the exploitation mechanics of a web-application code injection flaw — process ancestry is your highest-fidelity signal. Tune the allowlists to your environment before pushing to production.

Sigma Rules

---
title: Gitea Process Spawning Shell or Command Interpreter
description: Detects the Gitea server process spawning shells or common post-exploitation binaries, consistent with code injection exploitation such as CVE-2026-60004. The gitea process should never legitimately execute shells or system utilities as children.
references:
  - https://www.cisa.gov/news-events/alerts/2026/08/25/cisa-adds-one-known-exploited-vulnerability-catalog
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/08/25
tags:
  - attack.initial_access
  - attack.t1190
  - attack.execution
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentCommandLine|contains:
      - '/gitea'
      - 'gitea web'
  selection_child:
    CommandLine|contains:
      - '/bin/sh'
      - '/bin/bash'
      - '/bin/dash'
      - 'curl '
      - 'wget '
      - 'nc '
      - 'ncat'
      - 'python'
      - 'perl'
      - 'base64'
      - 'chmod'
      - 'chown'
  condition: selection_parent and selection_child
falsepositives:
  - Custom Gitea hooks or external tooling invoked by administrators — baseline and allowlist known hook scripts
level: high
---
title: Web Shell or Suspicious File Written to Gitea Working Directories
description: Detects creation of executable or script files in Gitea data and custom directories, a common post-exploitation artifact following code injection against self-hosted Git services such as CVE-2026-60004.
references:
  - https://www.cisa.gov/news-events/alerts/2026/08/25/cisa-adds-one-known-exploited-vulnerability-catalog
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/08/25
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: linux
detection:
  selection_path:
    TargetFilename|contains:
      - '/gitea-repositories/'
      - '/gitea/custom/'
      - '/gitea/data/'
      - '/gitea/tmp/'
      - '/var/lib/gitea/'
  selection_ext:
    TargetFilename|endswith:
      - '.sh'
      - '.php'
      - '.py'
      - '.pl'
      - '.so'
  condition: selection_path and selection_ext
falsepositives:
  - Legitimate Git hooks deployed by developers — review content and provenance of any hit
level: medium
---
title: Outbound Connection from Gitea Process to Uncommon Destination
description: Detects the Gitea server process initiating outbound network connections, which may indicate reverse shell activity or payload retrieval following exploitation of CVE-2026-60004. Baseline legitimate destinations (database, mail relay, webhook targets) before deployment.
references:
  - https://www.cisa.gov/news-events/alerts/2026/08/25/cisa-adds-one-known-exploited-vulnerability-catalog
  - https://attack.mitre.org/techniques/T1071/
author: Security Arsenal
date: 2026/08/25
tags:
  - attack.command_and_control
  - attack.t1071
logsource:
  category: network_connection
  product: linux
detection:
  selection:
    Image|contains: 'gitea'
    Initiated: 'true'
  filter_known_good:
    DestinationPort:
      - 25
      - 443
      - 5432
      - 3306
      - 6379
  condition: selection and not filter_known_good
falsepositives:
  - Legitimate webhook delivery to CI/CD systems on non-standard ports — baseline webhook targets
level: medium

KQL — Microsoft Sentinel / Defender

If you ingest Linux Syslog or CEF from your Gitea hosts into Sentinel (and you should — SCM infrastructure belongs in your SIEM), this query hunts for the gitea process spawning command interpreters, the highest-fidelity exploitation signal for a code injection flaw. The second query hunts suspicious file writes in Gitea working paths via auditd/Syslog ingestion.

// Hunt 1: gitea process spawning shells or post-exploitation tooling (auditd via Syslog)
Syslog
| where TimeGenerated > ago(7d)
| where SyslogMessage has "gitea"
| where SyslogMessage has_any ("/bin/sh", "/bin/bash", "/bin/dash", "curl", "wget", "nc ", "python", "perl", "base64 -d", "chmod +x")
| extend ParsedMsg = SyslogMessage
| project TimeGenerated, Computer, ProcessName, ParsedMsg, SeverityLevel
| order by TimeGenerated desc

// Hunt 2: suspicious file creation in Gitea working directories (auditd SYSCALL/AVC or file integrity logs)
Syslog
| where TimeGenerated > ago(7d)
| where SyslogMessage has_any ("gitea-repositories", "/var/lib/gitea", "gitea/custom", "gitea/tmp")
| where SyslogMessage has_any (".sh", ".py", ".php", ".pl", ".so")
| where SyslogMessage has_any ("open", "creat", "write", "chmod")
| project TimeGenerated, Computer, SyslogMessage
| order by TimeGenerated desc

// Hunt 3: outbound network connections from Gitea hosts to rare external destinations (CEF firewall data)
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DeviceAction !in ("deny", "drop")
| summarize ConnectionCount = count(), DistinctPorts = dcount(DestinationPort) by SourceIP, DestinationIP, DestinationPort
| where SourceIP in (dynamic(["<GITEA_HOST_IP_1>", "<GITEA_HOST_IP_2>"]))
| order by ConnectionCount asc

Velociraptor VQL

For rapid endpoint triage of a suspected-compromised Gitea host, this artifact combines process listing with network connection correlation to surface shells running under the gitea service account and unexpected outbound connections.

-- Hunt for suspicious processes and connections on a Gitea host (CVE-2026-60004 triage)
-- Part 1: processes running under the gitea/git service account or spawned from gitea paths
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE (Username =~ 'git|gitea' AND CommandLine =~ 'sh|bash|dash|curl|wget|nc |ncat|python|perl|base64')
   OR Exe =~ '/bin/(ba)?sh|/usr/bin/(curl|wget|nc|ncat|python|perl)'

-- Part 2: run separately — netstat for unexpected outbound connections from the host
SELECT Pid, Name, LocalAddr, LocalPort, RemoteAddr, RemotePort, State
FROM netstat()
WHERE State = 'ESTABLISHED'
  AND RemoteAddr !~ '^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|127\.)'
  AND Name =~ 'gitea|sh|bash|curl|wget|nc|python'

Verification & Hardening Script

Use this Bash script on Gitea hosts to check the installed version against the patched release, enumerate post-exploitation indicators (unexpected child processes, world-writable artifacts, new authorized_keys, rogue cron/systemd persistence), and confirm service exposure. Replace FIXED_VERSION with the patched version from the official Gitea advisory for CVE-2026-60004.

#!/bin/bash
# CVE-2026-60004 Gitea triage and verification script
# Run as root on Gitea hosts. Review output before taking action.

FIXED_VERSION="REPLACE_WITH_PATCHED_VERSION"  # e.g., 1.25.x per Gitea advisory

echo "=== [1] Installed Gitea version ==="
sudo -u git /usr/local/bin/gitea --version 2>/dev/null || gitea --version 2>/dev/null || echo "gitea binary not found in default paths"

echo "=== [2] Gitea process tree (look for shell/utility children) ==="
GITEA_PID=$(pgrep -f 'gitea web' | head -1)
if [ -n "$GITEA_PID" ]; then
  pstree -ap "$GITEA_PID"
else
  echo "gitea web process not found"
fi

echo "=== [3] Shells or tooling running as git/gitea user ==="
ps -eo user,pid,ppid,cmd | grep -E '^(git|gitea)' | grep -E '(sh|bash|dash|curl|wget|nc|ncat|python|perl)' | grep -v grep

echo "=== [4] Recent files in Gitea data/tmp/custom directories (last 14 days) ==="
for d in /var/lib/gitea /home/git/gitea /opt/gitea; do
  [ -d "$d" ] && find "$d" -type f \( -name '*.sh' -o -name '*.py' -o -name '*.php' -o -name '*.so' \) -mtime -14 -ls 2>/dev/null
done

echo "=== [5] authorized_keys for git user (check for unexpected entries) ==="
cat /home/git/.ssh/authorized_keys 2>/dev/null | awk '{print $NF, substr($0,1,40)}'

echo "=== [6] Cron and systemd persistence for git user ==="
crontab -u git -l 2>/dev/null
ls -la /etc/systemd/system/ | grep -iE 'gitea|git' ; systemctl list-units --type=service --state=running | grep -i gitea

echo "=== [7] Listening ports (expect 3000/22 or 2222 only) ==="
ss -tlnp | grep -E 'gitea|:3000|:2222|:22 '

echo "=== [8] Established outbound connections from gitea process ==="
ss -tnp | grep -i gitea

echo "=== [9] Gitea app.ini database/secret review (do not print secrets to shared logs) ==="
ls -la /etc/gitea/app.ini /var/lib/gitea/custom/conf/app.ini 2>/dev/null

echo ""
echo "ACTION: If installed version is below $FIXED_VERSION, upgrade immediately:"
echo "  1. Back up: gitea dump -c /etc/gitea/app.ini"
echo "  2. Download the patched binary from https://dl.gitea.com/gitea/ (verify GPG signature)"
echo "  3. systemctl stop gitea && replace binary && systemctl start gitea"
echo "  4. Confirm: gitea --version"

Remediation

1. Patch immediately — this is KEV-listed and actively exploited

• Upgrade Gitea to the version fixed for CVE-2026-60004 per the official Gitea advisory. Verify the exact patched release number against the advisory at gitea.com / the Gitea GitHub security advisories page, and confirm the CISA KEV entry details at the CISA KEV Catalog.
• Download binaries only from dl.gitea.com and verify the GPG signature and SHA256 checksum before deployment. Supply-chain discipline applies to your remediation path too.
• Run gitea dump before upgrading so you have a clean rollback point.
• FCEB agencies: Remediation is mandated under BOD 26-04 within the KEV-prescribed deadline. Track completion in your vulnerability management platform and report per directive requirements.

2. If you cannot patch today, reduce exposure

• Pull internet-facing Gitea instances behind VPN or IP allowlisting. There is rarely a good reason for a self-hosted SCM to be reachable from the open internet — mirror to a hosted service for public repos instead.
• Enforce SSO/MFA and disable open registration (DISABLE_REGISTRATION = true in app.ini) to shrink the authenticated attack surface.
• Place Gitea behind a reverse proxy with request inspection (WAF rules for anomalous payloads in API and web routes).
• Run Gitea under a dedicated unprivileged account (never root), with systemd hardening directives (ProtectSystem=strict, NoNewPrivileges=true, PrivateTmp=true) to constrain post-exploitation movement.

3. Assume breach — hunt before and after patching

Patching closes the door; it does not evict anyone already inside. For every Gitea host that was internet-exposed and unpatched during the exploitation window:

• Deploy the Sigma, KQL, and VQL detections above retrospectively over your log retention window (minimum 30 days; longer if available).
• Review Gitea audit logs for anomalous API token creation, permission changes, and bulk repository access.
• Rotate all credentials the Gitea host could touch: database passwords in app.ini, OAuth application secrets, deploy keys, webhook secrets, and any CI/CD tokens stored in repository configurations.
• Audit recent commits and release artifacts for unauthorized changes — diff release binaries against CI-built versions where possible. This is your supply-chain integrity check.
• If the triage script surfaces unexpected shells, files, or persistence: isolate the host, capture a forensic image, and engage IR. Do not simply patch and move on.

4. Fix the systemic issue

KEV additions for self-hosted developer tooling follow a pattern: attackers know these systems are high-value, often internet-exposed, and chronically under-patched because they're "dev infrastructure." Put SCM platforms, CI/CD servers, and artifact registries into your critical asset tier — same patch SLAs, same monitoring coverage, same IR playbooks as your domain controllers. If your Gitea host isn't in your SIEM today, that's the gap to close first.

Related Resources

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