Gitea: SSRF via Migration Asset Downloads Bypasses hostmatcher — Reads Internal Files and Cloud Metadata

CVE-2026-59765 is a server-side request forgery in Gitea's repository migration feature affecting all versions before 1.27.0. Gitea enforces SSRF protections via hostmatcher.NewDialContext() on webhook and clone URLs, validating resolved IPs at the TCP dial level. However, three code paths — in modules/uri/uri.go, services/migrations/gitea_uploader.go, and services/migrations/dump.go — use Go's bare http.Get() / http.DefaultClient, completely bypassing the hostmatcher. An attacker with migration privileges (admin or org owner) can craft release assets or PR patch URLs pointing to file:///etc/gitea/app.ini (exposing DB credentials, JWT signing secrets, SMTP passwords) or http://169.254.169.254/latest/meta-data/iam/security-credentials/ (stealing cloud IAM tokens). The fetched content lands in the migrated repo's release assets, readable by the attacker.

The vendor rates this MEDIUM at CVSS 6.8 (AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N). That score correctly captures the PR:H (high-privilege) prerequisite and the Scope:Changed / Confidentiality:High impact. But the vendor label under-weights what Gitea *is*: a self-hosted Git forge that frequently serves as the CI/CD backbone (Gitea Actions), artifact store, and secret vault for development teams. When an SSRF on this component leaks app.ini, the attacker gets database credentials and JWT signing keys — enough to forge admin tokens and pivot to supply-chain compromise. The 6.8 is defensible in isolation; for the role Gitea actually plays, HIGH is the right bucket.

Why this verdict

• PR:H narrows attacker population: The CVSS vector confirms high-privilege access is required. Default Gitea configuration restricts migration to admins and org owners — this is not an unauthenticated or low-privilege bug, which limits mass exploitation.
• Scope:Changed multiplies impact beyond the host: The SSRF reads files and services outside Gitea's own authorization boundary — cloud IAM credentials, database connection strings, and JWT signing secrets in app.ini. This is not a contained information disclosure.
• Role multiplier — CI/CD forge is a high-value target by definition: Gitea sits in the CI/CD + artifact stores category. ≥10% of Gitea installations serve as the primary development platform with Actions runners, making them the CI/CD backbone. Credential theft from app.ini yields database access and admin token forgery → full platform compromise → malicious commit injection → supply-chain pivot. This floors the verdict at HIGH per the deployment-role blast radius rule.
• ~34,000 internet-facing instances provide attack surface: Shodan data confirms significant external exposure. While many enterprise Gitea instances are internal-only, the external population is non-trivial and each is a potential target if the attacker can obtain or already holds an admin account.
• IMDSv2 adoption limits cloud metadata theft: AWS environments enforcing IMDSv2 are immune to the metadata theft vector (raw GET cannot complete the PUT token hop). This friction applies to the cloud-pivot path specifically but does not reduce the local file-read (file:///etc/gitea/app.ini) vector.

Why not higher?

CRITICAL would require either unauthenticated access or active exploitation. This CVE demands PR:H (admin/org owner), which means the attacker is either a malicious insider or has already compromised a high-privilege account through a separate chain. The bug amplifies an existing privileged position rather than granting initial access. No KEV listing and no observed campaigns further weigh against CRITICAL.

Why not lower?

MEDIUM ignores the deployment-role reality. Gitea is not a peripheral tool — it is the source-code repository, CI/CD engine, and often the secret store for development organizations. The SSRF reads app.ini containing database credentials and JWT signing secrets, which is a direct path to full platform takeover. The Scope:Changed designation in the CVSS vector confirms impact extends beyond the component. Downgrading past HIGH would require evidence that <1% of Gitea installations occupy the CI/CD high-value role, which contradicts Gitea's entire market position.

1. Enforce IMDSv2 on all cloud instances running Gitea — IMDSv2 requires a PUT request to obtain a session token before metadata is accessible. The raw http.Get() in the vulnerable code paths cannot complete this handshake, fully neutralizing the cloud metadata theft vector. Deploy within the noisgate mitigation SLA of 30 days for HIGH.
2. Restrict migration permissions to a dedicated admin account — Set [service].ENABLE_NOTIFY_MAIL = false and review [migrations] config. Ensure only a single, tightly-controlled admin account can perform migrations. This shrinks the attacker population to near-zero for external threat actors. Implement within 30 days.
3. Block outbound requests from Gitea to RFC 1918 and link-local ranges — Configure egress firewall rules (iptables, security groups, or network policy) on the Gitea host to deny outbound connections to 169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 from the Gitea process. This breaks both the cloud metadata and internal network scanning vectors at the network layer.
4. Disable open registration if not required — Open registration with default migration permissions gives external attackers a path to PR:H. Set [service].DISABLE_REGISTRATION = true or REGISTER_MANUAL_CONFIRM = true to prevent self-service account creation. This eliminates the external attacker's easiest path to the required privilege level.
5. Rotate secrets in app.ini post-patch — After upgrading to 1.27.0, rotate the JWT_SECRET, INTERNAL_TOKEN, SECRET_KEY, database password, and any SMTP credentials stored in app.ini. If the SSRF was exploited before patching, these secrets are compromised. Treat this as a mandatory post-remediation step.

Run this script on the Gitea host (or any host where you can query the Gitea API) as any user. It checks the Gitea version via the API. Usage: bash check_cve_2026_59765.sh https://gitea.example.com. No special privileges required — uses the public /api/v1/version endpoint.

#!/usr/bin/env bash
# check_cve_2026_59765.sh — Detect CVE-2026-59765 (Gitea SSRF via migration asset downloads)
# Usage: bash check_cve_2026_59765.sh <GITEA_BASE_URL>
# Exit codes: 1 = VULNERABLE, 0 = PATCHED, 2 = UNKNOWN

set -euo pipefail

if [ $# -lt 1 ]; then
  echo "Usage: $0 <GITEA_BASE_URL>"
  echo "Example: $0 https://gitea.example.com"
  exit 2
fi

BASE_URL="${1%/}"
API_URL="${BASE_URL}/api/v1/version"

# Fetch version
RESPONSE=$(curl -sf --max-time 10 "$API_URL" 2>/dev/null) || {
  echo "UNKNOWN — Could not reach Gitea API at $API_URL"
  exit 2
}

VERSION=$(echo "$RESPONSE" | grep -oP '"version"\s*:\s*"\K[^"]+' 2>/dev/null) || {
  echo "UNKNOWN — Could not parse version from API response"
  exit 2
}

echo "Detected Gitea version: $VERSION"

# Compare version — vulnerable if < 1.27.0
# Extract major.minor.patch
IFS='.' read -r MAJOR MINOR PATCH <<< "$(echo "$VERSION" | grep -oP '^[0-9]+\.[0-9]+\.[0-9]+')"

if [ -z "$MAJOR" ] || [ -z "$MINOR" ]; then
  echo "UNKNOWN — Could not parse version components from '$VERSION'"
  exit 2
fi

PATCH=${PATCH:-0}

if [ "$MAJOR" -lt 1 ]; then
  echo "VULNERABLE — Gitea $VERSION is affected by CVE-2026-59765 (fixed in 1.27.0)"
  exit 1
elif [ "$MAJOR" -eq 1 ] && [ "$MINOR" -lt 27 ]; then
  echo "VULNERABLE — Gitea $VERSION is affected by CVE-2026-59765 (fixed in 1.27.0)"
  exit 1
else
  echo "PATCHED — Gitea $VERSION includes the fix for CVE-2026-59765"
  exit 0
fi

Sources

1. GitLab Advisory Database — CVE-2026-59765
2. Kodem — CVE-2026-59765 Analysis
3. Gitea Blog — Release of 1.27.0
4. GitHub Advisory — GHSA-2wm4-vwp6-v7xc
5. SecurityWeek — Gitea Vulnerability Exposed 30,000 Deployments
6. Miggo Vulnerability Database — CVE-2026-59765
7. Hive Security — Gitea/Forgejo CVE Analysis
8. AlternativeTo — Gitea 1.27.0 Security Fixes