CKAN MCP Server SSRF Filter Bypass via Hostname Alias
First seen Aug 22, 2026 · Updated Aug 22, 2026 · CVSS 5.7
The CKAN MCP Server's earlier SSRF fix only blocked the literal hostname 'localhost' and dotted IPv4/bracketed IPv6 loopback literals, but missed alternate hostname aliases like 'ip6-localhost' and 'ip6-loopback' that resolve to loopback addresses. A remote caller invoking CKAN tools (e.g. ckan_package_search, sparql_query) with a crafted server_url/base_url parameter could bypass the filter and force the server to make requests to internal or loopback network locations. This is a moderate-severity SSRF bypass affecting a specific tool integration, not a novel or high-impact agentic exploitation technique.
Technical Analysis
The vulnerability lies in src/utils/http.ts, where URL validation checks only the parsed hostname string against a narrow denylist (exact match on 'localhost', dotted IPv4 literals, bracketed IPv6 literals) before the MCP server issues outbound HTTP requests on behalf of the tool call. Hostname aliases such as 'ip6-localhost' and 'ip6-loopback' are valid DNS names on many systems that resolve to loopback addresses at request time, so they pass the string-based filter but still cause the server to connect to internal/loopback network resources. The entry point is any MCP tool parameter (server_url/base_url) that an agent or caller controls when invoking ckan_package_search or sparql_query; an attacker supplying such a hostname can cause the MCP server to reach internal services and potentially exfiltrate CKAN-shaped response data back through the tool call. This crosses the tool/network boundary: an AI agent trusting a caller-supplied URL parameter effectively becomes an SSRF proxy into the server's internal network.
Affected Systems
CKAN MCP Server; protocols: MCP
Detection Signatures
- server_url or base_url parameters containing hostnames such as ip6-localhost, ip6-loopback, or other non-standard loopback aliases
- Outbound HTTP requests from MCP server process to loopback/internal addresses immediately following a tool invocation with an attacker-controlled URL parameter
- Log entries showing CKAN tool calls (ckan_package_search, sparql_query) with server_url values that do not match expected public CKAN portal domains
- DNS resolution of unusual hostname aliases to 127.0.0.1/::1 from within the MCP server host
Remediation Steps
- 1
Upgrade CKAN MCP Server
Update to version 0.4.106 or later, which replaces the single 'localhost' string check with a blocked-hostname Set covering ip6-localhost, ip6-loopback, and related aliases.
- 2
Resolve before validating
Validate the resolved IP address (post-DNS-resolution) against a denylist of private/loopback/link-local ranges rather than relying solely on hostname string comparison, to prevent alias and DNS-rebinding bypasses.
- 3
Enforce allowlisting
Restrict server_url/base_url parameters to an explicit allowlist of trusted CKAN portal domains rather than attempting to blocklist all malicious variants.
- 4
Network segmentation
Run MCP servers with egress filtering so outbound requests cannot reach internal/loopback services regardless of application-layer validation gaps.
- 5
Audit tool parameter trust
Review all MCP tools that accept caller-supplied URLs for similar SSRF validation logic and apply consistent, robust hostname/IP filtering across the codebase.
CVE / Advisory IDs
Industries Most Exposed
Respond to this threat
Pro subscribers get a full AI-generated incident-response playbook for this threat — detection, containment, eradication, and recovery steps — plus an unlimited AI Threat Advisor for questions about your environment.