CKAN MCP server SSRF guard bypassed for the third time

A GitHub security advisory published on 22 September 2026 says the npm package @aborruso/ckan-mcp-server, maintained by aborruso, contains a server-side request forgery flaw that lets a caller steer the server into making requests to internal addresses. The advisory, tracked as GHSA-798p-78g2-v556 and CVE-2026-61612, says all versions carrying the guard are affected, including the current latest release 0.4.107, and that no patch is available.

The package is a Model Context Protocol server, a component that exposes tools to an AI agent. According to the advisory, every tool takes a caller-supplied server_url argument, which flows into the functions that make CKAN API calls and SPARQL queries. A guard function named validateServerUrl is meant to stop those requests reaching private infrastructure.

The advisory says the guard checks only the hostname string. It blocks IP literals and three loopback alias names, but it never resolves the hostname to an IP address. A domain name that resolves to 127.0.0.1, to a cloud metadata address such as 169.254.169.254, or to an RFC-1918 private address therefore passes the check. The advisory notes that numeric encodings of IP addresses, such as decimal or hexadecimal forms, do not bypass the guard, because Node's URL parser converts them to dotted-decimal before the regular expression runs. Only the DNS-name route works.

This is the third reported bypass of the same function. The advisory states the guard was added for CVE-2026-33060 and extended for CVE-2026-53509, but that both earlier fixes only added more literal strings to the denylist, leaving the DNS-resolution gap untouched. The advisory describes the new issue as strictly worse than CVE-2026-53509, which only reached loopback, because this one reaches the instance metadata service.

The advisory rates the issue as effectively high severity for self-hosted deployments using the HTTP transport, where the server listens on POST /mcp without authentication. In that configuration, the advisory says, any remote client can trigger the request directly. In the default stdio deployment, an attacker would need prompt injection, meaning malicious text that steers the agent into supplying the tool argument. The official Cloudflare Worker endpoint is described as sandboxed and unable to reach loopback, private ranges or metadata addresses.

The flaw is non-blind, meaning the attacker sees the result. According to the advisory, when the response does not look like a CKAN reply, the server returns the raw body to the caller inside an error message beginning "CKAN API returned success=false". A published proof of concept runs the real package over the MCP protocol, points a tool at a local wildcard DNS name that resolves to 127.0.0.1, and shows a fake credential from a stand-in internal server echoed back to the client.

The advisory says a real attacker would not need the wildcard DNS service used in the demonstration, and could use any domain with an A or AAAA record pointing at an internal address, or DNS rebinding. The suggested fix is to resolve the hostname, validate every resolved IP against private and special ranges, and pin the connection to the validated address so a later re-resolution cannot swap in an internal target. Alternatively, the advisory recommends requiring the package's existing allowlist of permitted domains as a default-deny control, particularly for the HTTP transport. A hostname-string denylist, it concludes, cannot close this class of bug.