Gitea prior to 1.27.0 contains a server-side request forgery vulnerability

CVE-2026-34966 is a server-side request forgery in Gitea < 1.27.0. Three code paths — migration release-asset downloads, pull-request patch fetches, and OAuth2 avatar synchronization — call Go's bare http.Get() instead of the custom httplib client with Gitea's hostmatcher SSRF guard. An attacker who already holds admin or organization-owner privileges can craft a migration that points asset-download URLs at http://169.254.169.254/latest/meta-data/…, file:///data/gitea/conf/app.ini, or any RFC-1918 address. The response body is persisted as a release asset the attacker can later download, turning a blind SSRF into a full-read SSRF with data exfiltration. All Gitea versions from at least 1.20 through 1.26.x are affected; the fix shipped in 1.27.0 on 12 July 2026.

The vendor scored this 7.6 HIGH (CVSS 3.1) and 8.3 HIGH (CVSS 4.0). That rating is directionally correct but slightly generous for most real deployments. The PR:H requirement means the attacker must already control an admin-level Gitea account — a position that already grants read/write to every repository and every CI secret stored in Gitea. The SSRF's incremental value is lateral movement to cloud instance-metadata credentials and internal services, which is serious in cloud-hosted CI environments but conditional on IMDSv1 being available and internal services being unauthed. We shave ~0.8 points off the vendor score but keep the verdict firmly at HIGH because Gitea is, by definition, a CI/CD and source-code management component where a successful chain can cascade to supply-chain compromise.

Why this verdict

• PR:H gate is real friction. The attacker must already hold admin or org-owner privileges on Gitea. This is not a low-privilege or unauthenticated bug — it assumes a prior significant compromise of the Gitea identity layer, compounding downward pressure by ~0.8 points from the vendor's 7.6.
• Role multiplier: CI/CD source-code forge (HIGH floor). Gitea is canonically a CI/CD component. In cloud-hosted deployments, SSRF to 169.254.169.254 yields IAM credentials whose blast radius can be fleet-scale (S3, EC2, Lambda). In on-prem deployments, file:/// reads expose app.ini containing DB credentials and JWT signing keys. Both outcomes are supply-chain-adjacent. This floors the verdict at HIGH.
• Changed scope (S:C) is earned. The SSRF escapes the Gitea application boundary to reach cloud metadata services, internal APIs, and the local filesystem — resources the attacker's admin session was never intended to access.
• No exploitation in the wild and low EPSS (0.00314) mean there is no urgency multiplier pushing the score upward. The bug is a post-compromise lateral-movement primitive, not a first-stage entry vector.

Why not higher?

CRITICAL would require either active exploitation, unauthenticated access, or a scenario where the majority of Gitea installs are immediately exploitable. The PR:H requirement means the attacker has already breached an admin account — a non-trivial precondition. Additionally, IMDSv2 adoption on AWS (and equivalent on GCP/Azure) blocks the highest-impact cloud-metadata exfiltration path in modern deployments. The bug amplifies an existing compromise rather than creating one.

Why not lower?

Gitea is a supply-chain component by definition — it holds source code, CI secrets, and pipeline definitions. The SSRF's ability to read app.ini (DB creds, JWT secrets) and cloud IAM credentials from a single HTTP request represents a qualitative escalation beyond what even a Gitea admin should be able to do. Roughly 34,000 instances are internet-facing, with ~4,000 on cloud platforms where metadata SSRF is most dangerous. Downgrading to MEDIUM would undervalue the blast radius when the chain succeeds.

1. Enforce IMDSv2 on all cloud instances hosting Gitea — IMDSv2 requires a PUT-based token exchange before metadata reads succeed. A GET-only SSRF like this one cannot obtain the token, completely neutralizing the cloud-credential theft path. Deploy within the noisgate HIGH mitigation SLA of 30 days if you cannot patch Gitea immediately.
2. Disable repository migration for non-site-admin users — Set [migrations] ALLOWED_DOMAINS to an empty list or set DISABLE_MIGRATIONS = true in app.ini to eliminate the primary attack surface. This breaks legitimate migration workflows but removes the SSRF entry point entirely.
3. Enforce MFA on all Gitea admin accounts — The PR:H requirement means MFA on admin accounts directly raises the cost of reaching the vulnerable code path. Use TOTP or WebAuthn — not email-based OTP.
4. Network-segment the Gitea server away from sensitive internal services — Place Gitea in a DMZ or isolated VLAN with egress filtering that blocks RFC-1918, link-local (169.254.0.0/16), and localhost destinations. This limits SSRF blast radius even if the vulnerability is triggered.
5. Rotate app.ini secrets and DB credentials after patching — If you suspect exploitation, the SSRF may have already exfiltrated app.ini. Rotate JWT_SECRET, INTERNAL_TOKEN, SECRET_KEY, LFS_JWT_SECRET, and database passwords after upgrading to 1.27.0.

Run this on the Gitea server itself (or any host that can reach the Gitea API). Requires curl and jq. Invoke as: bash check_cve_2026_34966.sh https://gitea.example.com. No authentication needed — it checks the version endpoint.

#!/usr/bin/env bash
# check_cve_2026_34966.sh — Detect Gitea SSRF (CVE-2026-34966)
# Usage: bash check_cve_2026_34966.sh <GITEA_BASE_URL>
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 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%/}"

# Fetch Gitea version from the API
VERSION_JSON=$(curl -sf --max-time 10 "${BASE_URL}/api/v1/version" 2>/dev/null) || {
  echo "UNKNOWN — could not reach ${BASE_URL}/api/v1/version"
  exit 2
}

VERSION=$(echo "$VERSION_JSON" | jq -r '.version // empty' 2>/dev/null)
if [ -z "$VERSION" ]; then
  echo "UNKNOWN — could not parse version from API response"
  exit 2
fi

echo "Detected Gitea version: $VERSION"

# Compare versions: fixed in 1.27.0
# Extract major.minor.patch
IFS='.' read -r MAJOR MINOR PATCH <<< "$(echo "$VERSION" | sed 's/-.*//' | sed 's/+.*//')"
MAJOR=${MAJOR:-0}; MINOR=${MINOR:-0}; PATCH=${PATCH:-0}

FIXED_MAJOR=1; FIXED_MINOR=27; FIXED_PATCH=0

if [ "$MAJOR" -gt "$FIXED_MAJOR" ] 2>/dev/null; then
  echo "PATCHED — version $VERSION >= 1.27.0"
  exit 0
elif [ "$MAJOR" -eq "$FIXED_MAJOR" ] 2>/dev/null; then
  if [ "$MINOR" -gt "$FIXED_MINOR" ] 2>/dev/null; then
    echo "PATCHED — version $VERSION >= 1.27.0"
    exit 0
  elif [ "$MINOR" -eq "$FIXED_MINOR" ] 2>/dev/null; then
    if [ "$PATCH" -ge "$FIXED_PATCH" ] 2>/dev/null; then
      echo "PATCHED — version $VERSION >= 1.27.0"
      exit 0
    fi
  fi
fi

echo "VULNERABLE — version $VERSION < 1.27.0 (CVE-2026-34966)"
exit 1

Sources

1. CVE-2026-34966 Detail — THREATINT
2. Gitea 1.27.0 Release Notes
3. GHSA-2wm4-vwp6-v7xc — GitHub Security Advisory
4. Gitea 1.27.0 Patches Major Security Flaws — AlternativeTo
5. Gitea 1.27 Delivers 45 Security Fixes — LinuxSecurity
6. Gitea Vulnerability Exposed 30,000 Deployments — SecurityWeek
7. Gitea June 2026 Security Release Explained — Hive Security