Description

CKAN MCP Server is a tool for querying CKAN open data portals. A known vulnerability CVE-2026-33060 indicated tools including ckan_package_search and sparql_query that accept a base_url parameter had the risk of making HTTP requests to arbitrary endpoints without restriction. A fix was applied to filter out ip addresses. However, a method to bypass exists prior to version 0.4.106. CKAN MCP Server validates caller-supplied CKAN server URLs by inspecting only the parsed hostname string before issuing outbound HTTP requests. In `src/utils/http.ts`, hostname aliases such as `ip6-localhost` are not equal to `localhost`, are not dotted IPv4 literals, and are not bracketed IPv6 literals, so they pass the SSRF filter but can resolve to loopback when the server performs the request. A remote MCP caller that can invoke CKAN tools with a `server_url` can therefore make the server connect to local or private addresses and, for CKAN-shaped responses, receive response-derived data. The updated fix in version 0.4.106 replaced the single `hostname === 'localhost'` check with a blocked-hostname `Set` covering `ip6-localhost` and `ip6-loopback`.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.7",
  "pubDate": "2026-08-21T22:16:38.993Z",
  "pubdate": "2026-08-21T22:16:38.993Z",
  "executiveSummary": "A Server-Side Request Forgery (SSRF) bypass vulnerability exists in the CKAN MCP Server, tracked as CVE-2026-33060, affecting versions prior to 0.4.106. The vulnerability arises from insufficient hostname validation within the URL filtering logic implemented prior to the update. Specifically, tools such as ckan_package_search and sparql_query accept a base_url parameter that allows callers to specify custom CKAN server endpoints. While an initial fix was introduced to block direct IP addresses and strict localhost values, it failed to account for alternative loopback hostname aliases. As a result, an attacker possessing remote MCP caller capabilities can supply specialized hostname aliases to bypass the SSRF filter and force the server to execute outbound HTTP requests targeting internal, local, or private network addresses. Successful exploitation enables the attacker to interact with services running on loopback or private interfaces and potentially retrieve response-derived data for CKAN-shaped payloads. The risk is mitigated by updating to version 0.4.106, which introduces a comprehensive blocked-hostname Set covering known loopback aliases.",
  "technicalDetails": "The vulnerability resides in the URL validation and HTTP request handling mechanisms located within src/utils/http.ts of the CKAN MCP Server. The root cause of the bypass is an incomplete validation implementation that relied solely on inspecting parsed hostname strings before issuing outbound HTTP requests. Prior to version 0.4.106, the security control checked whether a caller-supplied hostname matched exact literal strings such as localhost, dotted IPv4 formats, or bracketed IPv6 literals, but failed to restrict recognized hostname aliases that resolve to loopback interfaces.\nDuring execution, when an unauthenticated or remotely authenticated MCP caller invokes CKAN tools like ckan_package_search or sparql_query with a maliciously crafted base_url parameter, the server processes the input. Because hostname aliases such as ip6-localhost do not equal localhost, are not formatted as dotted IPv4 literals, and do not appear as bracketed IPv6 literals, they successfully bypass the SSRF filter validation check. Once the validation check is cleared, the application performs an outbound HTTP request using the supplied URL. Upon resolution, these aliases resolve to loopback addresses, allowing the server to connect to local or private network resources that should otherwise be inaccessible.\nThe attack flow proceeds as follows: First, the remote attacker crafts an MCP tool invocation targeting a vulnerable CKAN MCP Server tool with a modified server_url or base_url containing the unblocked hostname alias (e.g., ip6-localhost). Second, the application processes the URL in src/utils/http.ts, where the inadequate hostname check evaluates the string as safe. Third, the underlying HTTP client initiates a connection to the resolved local address. Finally, if the internal service returns a CKAN-shaped response, the server processes and potentially leaks response-derived data back to the remote MCP caller. The vulnerable component is the HTTP utility module handling caller-supplied server URLs, impacting all versions prior to 0.4.106 without requiring specific authentication or privilege requirements beyond the ability to invoke MCP tool parameters over the exposed network interface."
}