CVE-2026-89430: Gitea Privilege Escalation Vulnerability

CVE-2026-89430 Overview

Gitea validated a push mirror's remote address against the [migrations] allow and block lists only at mirror creation time. Each subsequent synchronization passed the stored address directly to git push without re-validation. A repository administrator could aim push mirror synchronization at internal Git services and force-push repository contents to them. The flaw is a time-of-check to time-of-use (TOCTOU) weakness tracked as [CWE-367]. It was fixed in Gitea v28.0.0.

Critical Impact
Repository administrators can force-push arbitrary content to internal Git services reachable from the Gitea host, bypassing migrations allow and block lists.

Affected Products

Gitea (versions prior to v28.0.0)

Discovery Timeline

2026-10-06 - CVE-2026-89430 published to NVD
2026-10-07 - Last updated in NVD database

Technical Details for CVE-2026-89430

Vulnerability Analysis

Gitea supports push mirrors that replicate a repository's contents to a configured remote address on a schedule. The server administrator can restrict which hostnames or networks mirrors may contact using the [migrations]ALLOWED_DOMAINS and BLOCKED_DOMAINS configuration. Gitea applied those filters only at mirror creation. The stored remote URL was then handed to git push on every synchronization, with no fresh resolution check against the policy. An attacker with repository administrator rights, including on repositories they create themselves, could point a push mirror at a hostname whose DNS record later resolved to an internal or blocked address.

Root Cause

The underlying weakness is a check-then-use flaw [CWE-367]. Validation of the remote address occurred once, during creation, while the sensitive operation ran repeatedly. Because DNS resolution happens at push time, the address effectively used by git push can differ from the address that passed the allow and block list check.

Attack Vector

An authenticated user with administrator access to any repository creates a push mirror pointed at an attacker-controlled hostname that initially resolves to a public, policy-compliant address. After the mirror is accepted, the attacker changes the DNS record to resolve to an internal Git service such as a loopback endpoint, a private subnet, or a service only reachable from the Gitea host. On the next synchronization, Gitea invokes git push against the stored name, which now reaches the internal target. The push is force-based, which can overwrite branches on the internal service. This behavior is a server-side request forgery (SSRF) primitive layered on a TOCTOU race.

See the GitHub Security Advisory GHSA-hcgw-r9gf-8mph and Gitea Pull Request #39010 for the technical fix details.

Detection Methods for CVE-2026-89430

Indicators of Compromise

Push mirror configurations whose remote hostnames resolve to RFC1918, loopback, link-local, or other internal addresses at synchronization time.
Outbound Git over HTTPS or SSH traffic from the Gitea server to internal Git endpoints that were not previously contacted.
Mirror job logs showing successful pushes to hosts not present in the configured ALLOWED_DOMAINS list.

Detection Strategies

Audit the push_mirror database table and compare each stored remote_address against the current [migrations] allow and block lists, re-resolving DNS at audit time.
Correlate Gitea mirror synchronization events with network flow data to identify pushes targeting internal address space.
Alert on repository administrator actions that create or update push mirrors, especially where the remote host is newly registered or has a short DNS time-to-live.

Monitoring Recommendations

Forward Gitea application and audit logs to a central analytics platform and build detections for mirror create, update, and sync events.
Monitor egress from the Gitea host and block connections to internal Git service ports except from an explicit allow list.
Track DNS lookups performed by the Gitea process for mirror hostnames that resolve to private ranges.

How to Mitigate CVE-2026-89430

Immediate Actions Required

Upgrade Gitea to v28.0.0 or later, which re-validates the resolved address on each push mirror synchronization.
Enumerate existing push mirrors and remove or re-create any whose remote hostnames are attacker-controlled or resolve to internal networks.
Restrict repository administrator assignment and review which users can create repositories and configure mirrors.

Patch Information

The fix is included in Gitea Release v28.0.0. The code changes are available in Gitea Pull Request #39010 and Gitea Pull Request #39426. Release notes are published on the Gitea Blog Release Announcement.

Workarounds

Place the Gitea server behind an egress proxy that denies connections to internal address ranges and to any host not explicitly listed in ALLOWED_DOMAINS.
Enforce network segmentation so the Gitea host cannot reach internal Git services directly.
Disable the push mirror feature in app.ini by removing the capability from the [mirror] section until upgrade is possible.

bash

# Example app.ini hardening for Gitea push mirrors
[mirror]
ENABLED = false

[migrations]
ALLOWED_DOMAINS = github.com,gitlab.com
BLOCKED_DOMAINS = 127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,169.254.0.0/16,::1,fc00::/7
ALLOW_LOCALNETWORKS = false