CVE-2026-70357

Executive Summary

CVE-2026-70357 is a server-side request forgery (SSRF) vulnerability in Gitea's repository migration functionality. Gitea validates a migration destination hostname against its network allow and block lists before invoking Git, but the Git subprocess independently performs its own DNS resolution when connecting — creating a time-of-check-to-time-of-use (TOCTOU) gap. An attacker who can initiate a migration and control DNS resolution for the destination hostname can rebind the address between validation and connection, causing Gitea to reach internal or blocked network addresses.

Technical Analysis

The vulnerability class is CWE-918 (Server-Side Request Forgery). The core defect is a discrepancy between two independent resolution and validation paths:

1. Validation path: Gitea checks the migration destination hostname against its configured network allow and block lists. Per the NVD description, this validation is performed in the migration HTTP client's dialer.
2. Execution path: Gitea then invokes the Git binary as a subprocess to perform the repository clone. The Git subprocess performs its own independent DNS resolution at connection time — it does not reuse the validated address from the HTTP client dialer.

Because these two operations are decoupled, there is a window between validation and connection. An attacker who controls the DNS record (or whose target hostname resolves through an attacker-influenced resolver) can return a benign, allow-listed address during Gitea's validation step, then return an internal or otherwise blocked address when Git connects.

Key architectural observations derivable from the description:

• The affected path is the Git clone operation executed as a subprocess.
• Validation performed in the migration HTTP client's dialer does not protect the independently connecting Git subprocess — the two components resolve names separately.
• The flaw maps to classic DNS rebinding / TOCTOU SSRF rather than a simple allow-list bypass.

Affected versions, patch details, and vendor fix information are not available. No affected version range, commit reference, or advisory has been published in the data provided. This report describes the vulnerability class and mechanism strictly as documented; no specific function names, file paths, or parameters are invented because none appear in the source description.

Exploitation Scenarios

The following chain is inferred from the vulnerability class (TOCTOU DNS-rebinding SSRF). No public PoC is available; the attack chain is inferred from the vulnerability class.

1. Reconnaissance / target identification: The attacker identifies an exposed Gitea instance where they possess (or can obtain) the ability to start a repository migration — typically an authenticated user with migration privileges or an unauthenticated migration endpoint where enabled. The attacker also controls DNS for a hostname they will supply as the migration destination (e.g., an attacker-owned domain with a low-TTL A/AAAA record).

2. Triggering the flaw: The attacker submits a repository migration specifying their controlled hostname as the source. During validation, the attacker's DNS returns an allow-listed/public IP address, satisfying Gitea's network allow/block list check in the migration HTTP client's dialer.

3. Payload / execution method (vulnerability-class level): Before or during the Git subprocess's independent resolution and connection, the attacker changes the DNS record (or relies on round-robin/rebinding) so the hostname now resolves to a blocked internal address. The Git clone subprocess connects to the attacker-chosen internal destination because its resolution is not bound to the previously validated address.

4. Post-exploitation impact: Git connects to the blocked internal address. Depending on the internal service reached, the attacker may interact with internal-only HTTP(S) services, metadata endpoints, or other network resources reachable from the Gitea host. The attack operates within the network position and privileges of the Gitea server. Because exploitation requires the ability to start a migration and control DNS for the destination (a non-trivial precondition), the CVSS attack complexity is assessed as High; a low-privileged authenticated user is a reasonable minimum requirement (PR:L).

Impact Assessment

• Confidentiality: High — SSRF can expose internal services and sensitive responses accessible from the Gitea host.
• Integrity: High — interaction with internal services may permit state-changing requests where the reached service accepts them.
• Availability: None assumed — the flaw does not inherently disrupt service.
• Scope: Changed — the vulnerability in Gitea's migration logic crosses a trust boundary into the internal network and the separately executing Git subprocess.
• Blast radius: Any Gitea instance with repository migration enabled and network allow/block lists configured as an intended SSRF control. The control is bypassable for the Git clone path.
• Business impact: The network allow/block list is a security boundary that administrators rely on to prevent SSRF. CVE-2026-70357 undermines that boundary for the migration Git clone path, potentially exposing internal-only services (including cloud metadata endpoints and internal admin interfaces) to an attacker with migration rights.

Detection Guidance

Sigma Rule

title: Gitea Repository Migration DNS-Rebinding SSRF Attempt
id: 9f2c1a44-7b3e-4d5a-9c1e-gitea70357
status: experimental
description: Detects Gitea repository migration events that may indicate DNS rebinding against the Git clone path (CVE-2026-70357)
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-70357
author: valtersit.com
logsource:
  product: gitea
  service: audit
detection:
  selection:
    action|contains:
      - 'migrate'
      - 'repo.migration'
    message|contains:
      - 'migration'
  condition: selection
level: medium
tags:
  - attack.t1190
  - cwe.918

YARA Rule

rule CVE_2026_70357_Gitea_Migration_SSRF
{
    meta:
        description = "Detects references to Gitea migration SSRF / DNS rebinding indicators in logs or config"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-70357"
        cve = "CVE-2026-70357"
    strings:
        $mig = "migration" nocase
        $git = "git clone" nocase
        $ssrf1 = "block list" nocase
        $ssrf2 = "allow list" nocase
        $ssrf3 = "dialer" nocase
    condition:
        $mig and $git and any of ($ssrf*)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-70357 Gitea Repository Migration SSRF Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/api/v1/repos/migrate"; http.header; content:"Host"; threshold:type limit, track by_src, count 5, seconds 60; classtype:attempted-recon; sid:202670357; rev:1;)

Elastic Detection

sequence by process.entity_id with maxspan=10s
  [process where process.name == "gitea" and event.action : "repository.migration.start"]
  [process where process.name : "git" and process.args : "clone*"]

Splunk SPL Query

index=gitea OR index=web
  (message="*migrat*" OR uri="*repos/migrate*")
  (message="*git clone*" OR message="*dns*")
| stats count values(message) by src_ip, host, uri
| where count > 0
| table _time, host, src_ip, uri, count, values(message)

Wazuh OSSEC Rule

<group name="gitea,web,cve_2026_70357">
  <rule id="100357" level="10">
    <decoded_as>json</decoded_as>
    <field name="action">repository.migration.start</field>
    <description>CVE-2026-70357: Gitea repository migration initiated - possible SSRF/DNS rebinding</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>ssrf,cwe_918,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor fix, affected version range, or workaround is published in the data provided.

1. Immediate mitigations:

   • Restrict who can initiate repository migrations; disable migration for untrusted users if not required.
   • Enforce egress network filtering at the host/container level so the Gitea process and any Git subprocess cannot reach internal or metadata addresses, independent of Gitea's allow/block lists.
   • Where possible, resolve migration destinations to fixed IPs at the network layer rather than relying solely on Gitea's in-process validation.
   • Monitor and alert on all git clone subprocess executions originating from Gitea migrations targeting unusual destinations.

2. Patch/upgrade steps:

   • No patch is currently available. Track the Gitea project's security advisories and release notes for a fix. When a patched release is published, upgrade immediately and re-verify that the Git clone path resolves and enforces the same allow/block list as the migration HTTP client's dialer.

3. Long-term hardening:

   • Pin or re-resolve hostnames once and pass the validated address to the Git subprocess, eliminating the TOCTOU gap at the architectural level (vendor-side change required).
   • Adopt defense-in-depth: treat SSRF allow/block lists as one layer among network egress controls, not as a sole boundary.
   • Reduce the privileges of the Gitea service account and isolate it in a segmented network zone.

References

• NVD — CVE-2026-70357: https://nvd.nist.gov/vuln/detail/CVE-2026-70357
• Gitea security advisories: https://github.com/go-gitea/gitea/security/advisories
• CWE-918 Server-Side Request Forgery: https://cwe.mitre.org/data/definitions/918.html
• MITRE ATT&CK T1190 — Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/
• CISA KEV Catalog (no entry for this CVE at time of writing): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No exploit code, public PoC, Nuclei template, or in-the-wild exploitation evidence is currently known for CVE-2026-70357. No threat actor campaigns have been associated with this CVE in the data provided.