CVE-2026-61612: Server-Side Request Forgery Bypass via DNS Resolution in CKAN MCP Server

The CKAN MCP Server is designed as a Model Context Protocol (MCP) server used to query and integrate public data portals configured with the CKAN open-source data management system. Organizations run this server to expose API interaction endpoints for Large Language Model (LLM) agents and orchestration engines. To handle queries dynamically, the application requires the capability to issue outbound HTTP requests to targeted CKAN platforms utilizing parameters supplied by the client.

To restrict the outbound surface to public endpoints and prevent exploitation, the developers implemented an endpoint validation mechanism. This validation routine, known as validateServerUrl, is intended to enforce a boundary that blocks requests directed toward local, loopback, and private network addresses.

However, because the check was implemented strictly at the string level, it failed to account for domain names that resolve to local interfaces. This structural omission exposed a direct path for Server-Side Request Forgery (SSRF), designated as CWE-918. Attackers can exploit this path to target cloud metadata services and internal diagnostic interfaces that are inaccessible from the open internet.

The core technical flaw lies in the sequence of validation and connection within the network logic of src/utils/http.ts. The implementation of the validation function relied on processing string-based hostname literals extracted from user-supplied URLs.

The routine checked if the hostname matched forbidden string arrays (e.g., 'localhost') or private IPv4 address patterns via a basic dotted-decimal regular expression: /^(\d+)\.(\d+)\.(\d+)\.(\d+)$/. If the input value did not match these specific configurations, the validation was bypassed and marked safe. The subsequent execution path then passed the unchecked string directly to standard client libraries like axios or Node's fetch API.

Because the verification process omitted programmatic DNS resolution, any hostname containing alphanumeric characters would pass the regular expression test. For example, the domain name 127.0.0.1.nip.io was parsed as a valid remote hostname because it is not literally equal to 'localhost' and fails to match the strict dotted-decimal format. During the HTTP client connection sequence, the system's underlying resolver mapped this host to the loopback IP (127.0.0.1), allowing an attacker to reach internal-only ports.

This vulnerability represents a Time-of-Check to Time-of-Use (TOCTOU) structural flaw. Because domain name checking occurred without querying actual target resolutions, DNS Rebinding and wildcard resolution techniques bypassed the logical security checks entirely.

Prior to the release of version 0.4.108, the code lacked any dynamic DNS validation layer. The fixed version introduced a structural remediation by introducing safe lookup hooks inside the HTTP client configurations.

The remediation establishes a unified validator function isBlockedIp to check both IPv4 and IPv6 target strings:

export function isBlockedIp(ip: string): boolean {
  const v = ip.toLowerCase().trim();
  if (v.includes(':')) {
    if (v === '::1' || v === '::') return true;
    if (v.startsWith('fc') || v.startsWith('fd')) return true;
    if (v.startsWith('fe80')) return true;
    if (v.startsWith('::ffff:')) return true;
    return false;
  }
  const m = v.match(/^(\d+)\.(\d+)\.(\d+)\.(\d+)$/);
  if (!m) return false;
  const o1 = Number(m[1]);
  const o2 = Number(m[2]);
  return (
    o1 === 0 ||
    o1 === 10 ||
    o1 === 127 ||
    (o1 === 100 && o2 >= 64 && o2 <= 127) ||
    (o1 === 169 && o2 === 254) ||
    (o1 === 172 && o2 >= 16 && o2 <= 31) ||
    (o1 === 192 && o2 === 168) ||
    o1 === 255
  );
}

To safeguard connections established via HTTP libraries, the patch implements a custom dns lookup function createSsrfSafeLookup. This component resolves the host dynamically and validates each resolved address prior to allowing the TCP handshake to occur:

export function createSsrfSafeLookup(dnsModule: DnsLookupModule) {
  return function ssrfSafeLookup(hostname: string, options: any, callback: any): void {
    if (typeof options === 'function') {
      callback = options;
      options = {};
    }
    const family = options && typeof options === 'object' ? options.family : undefined;
    dnsModule.lookup(hostname, { all: true, family: family || 0 }, (err, addresses) => {
      if (err) {
        callback(err);
        return;
      }
      const list = Array.isArray(addresses) ? addresses : [addresses as ResolvedAddress];
      for (const a of list) {
        if (isBlockedIp(a.address)) {
          callback(new Error(
            `Access to private/internal IP addresses is not allowed ("${hostname}" resolves to ${a.address}).`
          ));
          return;
        }
      }
      if (options && options.all) {
        callback(null, list);
        return;
      }
      callback(null, list[0].address, list[0].family);
    });
  };
}

Additionally, direct fetch operations (such as SPARQL tooling queries) now execute assertHostnameResolvesSafe prior to initializing the HTTP protocol phase, forcing validation of the actual resolved IP addresses. The mitigation of TOCTOU DNS hazards is accomplished by pinning target addresses.

Exploiting this flaw requires an attacker to interact with the exposed MCP server tools. An attacker sends a formatted request containing a malicious URL parameter designed to exploit DNS resolution.

The primary attack vector uses a wildcard DNS service such as nip.io or lvh.me to point back to the local host or AWS infrastructure addresses. An attacker target configuration can resolve directly to 127.0.0.1 or the link-local metadata address 169.254.169.254:

• http://local-test.127.0.0.1.nip.io resolves to 127.0.0.1
• http://aws-metadata.169.254.169.254.nip.io resolves to 169.254.169.254

The exploit is executed by issuing a JSON-RPC request to the MCP server API to run a tool, such as ckan_status_show or ckan_package_search:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "ckan_status_show",
    "arguments": {
      "server_url": "http://aws-metadata.169.254.169.254.nip.io"
    }
  }
}

The server receives the input parameter and evaluates the host against the regex check. Because the host string contains alphabetical characters (aws-metadata), the check succeeds.

Next, the client HTTP stack resolves the hostname and makes an HTTP connection to the AWS IMDS endpoint. The server reads the response from the link-local address and outputs the resulting session metadata or access tokens in the JSON-RPC response.

The impact of this vulnerability depends on the deployment architecture of the CKAN MCP Server. In cloud environments like AWS, GCP, or Azure, the server can access internal metadata endpoints.

On AWS, an attacker can extract credentials by calling the Instance Metadata Service (IMDS). If IMDSv1 is active or IMDSv2 hop limits allow access, the attacker can extract IAM credentials associated with the server's execution role.

If the server is deployed on-premise, this vulnerability allows attackers to bypass network perimeters. Attackers can scan local network services, communicate with databases, or access admin interfaces running on 127.0.0.1 or local subnets.

The primary remediation for this vulnerability is upgrading @aborruso/ckan-mcp-server to version 0.4.108 or later. This update changes the connection pipeline to validate resolved IP addresses instead of hostname strings.

For systems that cannot be immediately updated, administrators can restrict outgoing network traffic using firewalls. Egress filtering rules should block the server from connecting to loopback (127.0.0.1/8), private networks (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), and local link addresses (169.254.0.0/16).

Administrators can also configure domain restrictions by setting the CKAN_ALLOWED_DOMAINS environment variable. This variable restricts the server's outgoing connections to a defined list of trusted domain names.