CVE-2026-101029: Gitea Auth Bypass Vulnerability

CVE-2026-101029 Overview

CVE-2026-101029 is a Server-Side Request Forgery (SSRF) vulnerability in Gitea's repository migration and pull mirror functionality. The egress validation checks can be bypassed when a hostname returns multiple DNS answers, because the address validated during the check is not necessarily the address that Git later connects to. A low-privileged user with permission to create migrations or mirrors can direct the Gitea server to internal services, reading from and writing to reachable internal Git or HTTP endpoints. Content from internal responses can also be disclosed through migration and mirror error messages, mapping to [CWE-209] Information Exposure Through an Error Message.

Critical Impact
Authenticated attackers can reach internal network services and exfiltrate response content through error messages, bypassing egress controls intended to prevent SSRF.

Affected Products

Gitea versions prior to v28.0.0
Gitea repository migration feature
Gitea pull mirror feature

Discovery Timeline

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

Technical Details for CVE-2026-101029

Vulnerability Analysis

Gitea performs egress validation on user-supplied URLs before initiating repository migrations or pull mirror synchronization. The validation resolves the hostname and checks whether the returned IP address targets an internal or restricted network. The flaw is a classic Time-of-Check to Time-of-Use (TOCTOU) condition applied to DNS resolution, often called DNS rebinding when the hostname returns multiple answers.

When the attacker-controlled hostname returns multiple DNS answers, Gitea validates one address but Git may subsequently connect to a different address in the response set. An attacker-controlled DNS server can return both a public address and an internal address, allowing the follow-up Git or HTTP connection to hit internal infrastructure.

Beyond the SSRF primitive, the server returns verbose error messages that embed content from the backend response. This permits exfiltration of internal data even when no interactive protocol handshake succeeds.

Root Cause

The root cause is that hostname validation and the actual network connection use independent DNS lookups. The validator inspects resolved addresses once, but the Git client performs its own resolution later. There is no pinning of the validated IP to the subsequent connection, so a multi-answer DNS response or a short TTL rebind defeats the check.

Attack Vector

A low-privileged authenticated user creates a repository migration or pull mirror pointing to a hostname under attacker control. The DNS server returns multiple answers that include at least one internal address, or rebinds between the validation and connection steps. Git then connects to an internal Git or HTTP endpoint, and any response body or error returned by the backend is surfaced in migration or mirror error messages visible to the attacker.

See the GitHub Advisory GHSA-6g2h-xpg3-rm48 and Gitea Pull Request #39010 for technical details of the fix.

Detection Methods for CVE-2026-101029

Indicators of Compromise

Repository migration or pull mirror jobs whose source URL hostnames resolve to RFC1918, loopback, link-local, or cloud metadata IP ranges.
Outbound Git or HTTP connections from the Gitea server process to internal services that have no legitimate relationship with Gitea.
Repeated migration or mirror failures that return response fragments from internal services inside the error message body.

Detection Strategies

Inspect Gitea application logs for migration and mirror error entries containing HTML, JSON, or Git protocol fragments that originate from internal hosts.
Correlate DNS resolver logs with Gitea egress connections to identify hostnames that return multi-answer responses mixing public and private addresses.
Audit the migrations and mirrors tables for source URLs with low-reputation domains, dynamic DNS providers, or hostnames created by low-privileged accounts.

Monitoring Recommendations

Monitor egress traffic from the Gitea host to internal subnets and metadata endpoints such as 169.254.169.254 for cloud deployments.
Alert on any new migration or mirror task created by non-admin accounts targeting non-standard hosting domains.
Capture full error response bodies in security telemetry to detect data disclosure patterns consistent with SSRF exfiltration.

How to Mitigate CVE-2026-101029

Immediate Actions Required

Upgrade Gitea to v28.0.0 or later, which contains the fixes delivered in Pull Request #39010 and Pull Request #39426.
Review existing migration and pull mirror configurations and remove any targeting suspicious or attacker-controlled hostnames.
Restrict migration and mirror creation to trusted users until the upgrade is validated in production.

Patch Information

The fix is included in Gitea v28.0.0. Refer to the Gitea 28.0.0 release announcement for upgrade guidance. The patch pins validated addresses to the subsequent connection and sanitizes error output returned to the requesting user.

Workarounds

Place the Gitea instance behind an egress proxy that enforces an allow-list of permitted destination hosts and blocks RFC1918, loopback, and cloud metadata ranges.
Disable repository migration and pull mirror features for non-administrative users via Gitea role configuration until patching is complete.
Deploy network-level firewall rules that deny outbound connections from the Gitea host to internal management networks and cloud metadata services.

bash

# Example egress restriction in Gitea app.ini to limit allowed hosts
[migrations]
ALLOWED_DOMAINS = github.com,gitlab.com,bitbucket.org
BLOCKED_DOMAINS =
ALLOW_LOCALNETWORKS = false