CVE-2026-101027

Executive Summary

CVE-2026-101027 is a server-side request forgery (SSRF) bypass affecting Gitea instances that have configured [migrations] ALLOWED_DOMAINS. When an allowed hostname is supplied to the repository migration feature, the application validates the hostname against the allow list but fails to re-check the hostname's resolved IP address against local-network restrictions. An attacker who can start repository migrations and controls the DNS records of an allow-listed hostname can cause it to resolve to loopback or RFC1918/private addresses, subverting the ALLOW_LOCALNETWORKS = false control and enabling requests to internal services from the Gitea server. Instances without ALLOWED_DOMAINS configured are explicitly not affected by this specific bypass. No CVSS score, CWE assignment, EPSS score, or public exploit is currently available.

Technical Analysis

The vulnerability resides in the repository migration subsystem of Gitea. Gitea's migration feature allows users to import repositories from remote sources; because this feature causes the Gitea server itself to issue outbound HTTP(S) requests to a user-supplied host, it constitutes a classic SSRF attack surface. To constrain this surface, administrators can configure two independent controls:

• [migrations] ALLOWED_DOMAINS — an allow list of hostnames from which migrations may be sourced.
• [migrations] ALLOW_LOCALNETWORKS — a flag that, when set to false, is intended to block requests to loopback and private network ranges.

The flaw is a validation-ordering and validation-completeness defect. According to the NVD description, a hostname matching the ALLOWED_DOMAINS allow list "was accepted without checking its resolved address against the local-network restrictions." In other words, the allow-list check operated on the name presented by the user rather than on the address the name ultimately resolves to. The intended defense — resolving the hostname and rejecting requests whose target IP falls in loopback or private ranges — was not applied to allow-listed hostnames.

This creates a TOCTOU-adjacent / DNS-rebinding-style bypass: the attacker satisfies the name-based policy while the DNS resolution returns an address that violates the network-based policy. Because the attacker "control[s] the DNS of an allowed hostname," the trust boundary between hostname allow-listing and network reachability restrictions is broken. The two controls were designed to be defense-in-depth, but the implementation effectively let the weaker control (name matching) override the stronger one (address restriction).

The technical class is SSRF (CWE-918) with an allow-list bypass component. Note that Gitea's migration codebase is not further detailed in the available description; no specific function names, parameter names, or file paths are disclosed by the CNA or NVD, so this analysis intentionally stays at the mechanism level and does not speculate about internal identifiers. The affected Gitea versions are likewise not enumerated in the supplied data, and the vulnerability is marked UNPATCHED (0/4 patch confidence) with no vendor fix or workaround listed.

Key preconditions required for exploitation:

1. The Gitea instance has [migrations] ALLOWED_DOMAINS configured.
2. The attacker can initiate repository migrations (requires at least an authenticated account with repository-creation/migration privileges).
3. The attacker controls the DNS resolution of at least one hostname present on the allow list (e.g., via a subdomain takeover, an attacker-owned allowed domain, or control of an authoritative DNS server).
4. ALLOW_LOCALNETWORKS = false is set (otherwise there is no restriction to bypass).

The flaw is only exploitable when the allow-list control is enabled — instances without ALLOWED_DOMAINS are explicitly stated as not affected by this particular bypass. This is an important scoping fact: the presence of the allow list is the enabling condition, not a mitigating one.

Exploitation Scenarios

No public PoC is available; the following attack chain is inferred from the SSRF/allow-list-bypass vulnerability class and the NVD description. Specific internal implementation details (endpoints, parameters) are not disclosed and are not invented here.

1. Reconnaissance / target identification. The attacker confirms that the target runs Gitea (e.g., via the login page, version banner, or favicon) and identifies the repository migration feature. The attacker then determines whether ALLOWED_DOMAINS is configured — observable indirectly, for example, because migrations to non-listed domains are rejected. The attacker also determines whether ALLOW_LOCALNETWORKS is false, which is the default-hardened posture the bypass is meant to defeat.

2. Triggering the flaw class. The attacker needs an authenticated account (or access to one) able to create a migration. They identify or arrange a hostname that is present on the ALLOWED_DOMAINS list and whose DNS they control. This may be achieved through a legitimate allowed domain the attacker operates, a subdomain of an allowed domain that the attacker has taken over, or control of the authoritative DNS for an allowed name. They then create a migration whose source host is that allow-listed hostname.

3. Payload / execution at the vulnerability-class level. The attacker configures the controlled DNS name to resolve to an address that ALLOW_LOCALNETWORKS = false is supposed to block — a loopback address (127.0.0.0/8, ::1) or a private address (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, link-local, or cloud metadata ranges). Because the migration handler validates the hostname against the allow list but does not validate the resolved address, the server then issues its outbound migration request to the internal target. Depending on the target and the migration client's behavior, the attacker may observe response content or behavior differences (e.g., migration errors, timing) that leak information about the internal service.

4. Post-exploitation impact. Successful requests allow the attacker to reach internal services bound to loopback or the private network from the Gitea server's network context — potentially including administrative panels, internal APIs, metadata services, or databases not otherwise externally reachable. Depending on the migration feature's parsing behavior, an attacker may be able to read internal HTTP responses (as part of the repository-import procedure) or use the server as a pivot/scanning proxy into the local network. The primary impact is confidentiality (internal service disclosure) and potential further lateral movement; because the flaw is a validation bypass rather than remote code execution, the immediate impact is bounded by what internal endpoints the Gitea host can reach.

Impact Assessment

CVE-2026-101027 is an SSRF allow-list bypass affecting the confidentiality of internal network resources reachable by the Gitea server. CVSS subscores are not published (score and vector are N/A in the source data). An assessment consistent with the described mechanism is:

• Attack Vector: Network (the migration request is initiated over the network to the Gitea instance).
• Attack Complexity: High — requires the attacker to control DNS for an allow-listed hostname and to hold migration privileges.
• Privileges Required: Low — an authenticated account capable of starting migrations.
• User Interaction: None.
• Scope: Changed — the vulnerable component (Gitea) causes requests to a different security authority (internal network services).
• Confidentiality: High — internal service responses may be leaked via the migration process.
• Integrity: None typically.
• Availability: None typically.

Business impact. Affected systems are Gitea instances exposed to untrusted or semi-trusted users (e.g., public or multi-tenant Gitea deployments, software forges with open registration, or internal forges reachable by lower-privileged staff) that have both ALLOWED_DOMAINS configured and ALLOW_LOCALNETWORKS = false. The blast radius depends heavily on network placement: a Gitea server with broad internal reachability (flat network, cloud metadata endpoints, internal CI/registry/admin services) yields a much larger blast radius than an isolated instance. Because the attacker needs to "start repository migrations and control the DNS of an allowed hostname," the vulnerability is not trivially remote/unauthenticated, but in multi-tenant environments it can elevate a low-privileged forge user into a network pivot point. Prompt patching and network segmentation are the primary risk-reduction levers.

Detection Guidance

Sigma Rule

title: Gitea Migration SSRF Allow-List Bypass (CVE-2026-101027)
id: 8e9c1e2a-7b6f-4b3d-9c1a-101027cve000
status: experimental
description: Detects Gitea repository migration activity that may leverage the ALLOWED_DOMAINS allow-list bypass to reach local/private networks.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-101027
author: valtersit.com
date: 2026/01/01
logsource:
  category: application
  product: gitea
detection:
  selection:
    msg|contains:
      - 'Migration'
      - 'migrate'
  keywords:
    msg|re|i:
      - 'migrat(e|ion).*(http://|https://)'
      - '127\.0\.0\.'
      - 'localhost'
      - '10\.\d+\.\d+\.\d+'
      - '192\.168\.\d+\.\d+'
      - '169\.254\.169\.254'
      - '::1'
  condition: selection and keywords
level: high
tags:
  - attack.t1190
  - cve.2026.101027

YARA Rule

rule CVE_2026_101027_Gitea_Migration_SSRF
{
    meta:
        description = "Detects Gitea migration SSRF allow-list bypass artifacts (CVE-2026-101027)"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-101027"
        date = "2026-01-01"
        severity = "high"

    strings:
        $gitea = "Gitea" ascii nocase
        $migrate = "migrate" ascii nocase
        $allowed = "ALLOWED_DOMAINS" ascii
        $localnet = "ALLOW_LOCALNETWORKS" ascii
        $loopback = "127.0.0.1" ascii
        $rfc1918a = "10." ascii
        $private = "192.168." ascii
        $meta = "169.254.169.254" ascii

    condition:
        $gitea and $migrate and (2 of ($allowed, $localnet, $loopback, $private, $meta))
}

Suricata IDS Rule

alert http $HOME_NET any -> $HOME_NET any (msg:"CVE-2026-101027 Gitea Migration SSRF Allow-List Bypass Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/repo/migrate"; nocase; http.host; content:"127.0.0.1"; nocase; sid:2026101027; rev:1; reference:cve,2026-101027; classtype:attempted-recon; metadata:created_at 2026_01_01, updated_at 2026_01_01;)

alert http $HOME_NET any -> $HOME_NET any (msg:"CVE-2026-101027 Gitea Migration to Private Range"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/repo/migrate"; nocase; pcre:"/(?:10\.[0-9]{1,3}|192\.168\.[0-9]{1,3}|169\.254\.169\.254)/Ui"; sid:2026101028; rev:1; reference:cve,2026-101027; classtype:attempted-recon;)

Elastic Detection

sequence by process.entity_id
  [process where event.category == "process" and process.name == "gitea"]
  [network where event.category == "network" and
     (destination.ip like "127.*" or
      destination.ip like "10.*" or
      destination.ip like "192.168.*" or
      destination.ip like "169.254.*" or
      destination.ip == "::1") and
     process.name == "gitea"]

Splunk SPL Query

index=gitea OR index=web
| search (uri="/repo/migrate" OR uri="*/repo/migrate") AND http_method=POST
| rex field=form_data "(?<migrate_url>https?://[^&\s]+)"
| where match(migrate_url, "(?i)(127\.0\.0\.|localhost|10\.\d+\.\d+\.\d+|172\.(1[6-9]|2\d|3[01])\.\d+\.\d+|192\.168\.\d+\.\d+|169\.254\.169\.254|\[?::1\]?)")
| stats count min(_time) as first_seen max(_time) as last_seen by src_ip, user, migrate_url
| eval first_seen=strftime(first_seen,"%Y-%m-%d %H:%M:%S"), last_seen=strftime(last_seen,"%Y-%m-%d %H:%M:%S")
| sort - count

Wazuh OSSEC Rule

<group name="gitea,web,ssrf,">
  <rule id="1010270" level="12">
    <decoded_as>json</decoded_as>
    <field name="uri">/repo/migrate</field>
    <field name="http_method">POST</field>
    <regex field="form_data">(?i)(127\.0\.0\.|localhost|10\.\d+\.\d+\.\d+|172\.(1[6-9]|2\d|3[01])\.\d+\.\d+|192\.168\.\d+\.\d+|169\.254\.169\.254)</regex>
    <description>CVE-2026-101027: Gitea migration SSRF allow-list bypass attempt to local/private address</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>cve_2026_101027,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1. Immediate mitigations (no vendor fix available):

   • Because the bypass specifically depends on ALLOWED_DOMAINS being configured, administrators who cannot patch and do not strictly require the allow list may consider removing or disabling [migrations] ALLOWED_DOMAINS and instead relying on other controls — but note this changes the security trade-off and should be a deliberate decision. (Per the advisory, instances without ALLOWED_DOMAINS are not affected by this specific bypass.)
   • Keep ALLOW_LOCALNETWORKS = false enabled; do not assume the allow list replaces it. However, recognize that this setting alone is bypassed by the flaw when an allow-listed, DNS-controlled hostname resolves to a private/loopback address.
   • Restrict who can create/import repository migrations (limit migration privileges to trusted users or admin-only).
   • Apply network egress controls (egress firewall/NetworkPolicy) so the Gitea container/host cannot reach loopback-admin services, cloud metadata endpoints (169.254.169.254), or sensitive internal subnets.
   • Block/deny the Gitea host's access to cloud instance metadata through firewall rules and require IMDSv2/session-oriented metadata protections where applicable.
   • Monitor for DNS rebinding-style behavior; consider forcing resolution of migration hostnames against a controlled/authoritative resolver.

2. Patch/upgrade steps: No patch is currently identified. Track the Gitea security advisories and release notes; when a fixed release is published, upgrade to the earliest version that addresses CVE-2026-101027. Subscribe to the Gitea changelog and the GitHub Security Advisory database for the Gitea project. Re-verify ALLOWED_DOMAINS behavior after upgrading.

3. Long-term hardening:

   • Enforce address-level validation in addition to name-level validation for any user-controllable outbound request (resolve, then validate against a deny list of loopback/private/link-local/metadata ranges, and pin the resolved address to prevent rebinding).
   • Segment the Gitea host into a restricted network zone with least-privilege egress.
   • Adopt a defense-in-depth posture where allow-listing and network-reachability restrictions are both enforced rather than treated as alternatives.

References

• NVD — CVE-2026-101027: https://nvd.nist.gov/vuln/detail/CVE-2026-101027
• Gitea security advisories (project): https://github.com/go-gitea/gitea/security/advisories
• Gitea configuration documentation (ALLOWED_DOMAINS, ALLOW_LOCALNETWORKS): https://docs.gitea.com/
• MITRE ATT&CK — T1190 Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/
• CWE-918 — Server-Side Request Forgery (SSRF): https://cwe.mitre.org/data/definitions/918.html

Threat actor campaign and in-the-wild exploit information: none available from the provided data. CISA KEV: NO. EPSS: not yet scored by FIRST.org. PoC/Exploit code: none public at time of writing.