Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The MCP Apps UI resource (an interactive DataStore table rendered in the host's webview/iframe) communicates with its parent via postMessage. Its inbound message listener performs no event.origin validation, and its outbound messages are sent with target origin ''. Any window/frame able to reach the document can inject data into the table and interfere with the MCP UI handshake, and the UI's own JSON-RPC messages are broadcast without an origin restriction. Affected code src/resources/datastore-table-ui.ts (inline HTML): There is no allowlist of accepted origins for inbound messages and no fixed target origin for outbound messages. Impact - Content spoofing. A frame that can postMessage to the UI can supply arbitrary fields/records, causing the table to render fabricated rows and links (e.g. a phishing linkurl) that appear to come from the queried portal. (Values are HTML-escaped, so this is display spoofing, not script injection — no XSS.) - Handshake/UX interference.…
Recommended action: Upgrade to 0.4.112 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 serverurl 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…
Recommended action: Upgrade to 0.4.108 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The response cache derives its key from an ambiguous string serialization of the request parameters. canonicalizeParams joins sorted ${key}=${value} pairs with & and does not escape &, =, or the | field separators used in buildCacheKey. Two different logical parameter sets can therefore serialize to the same key and share one cache entry. Because the cached value is whatever the upstream returned for whichever request populated the entry first, an attacker can prime a colliding key so a victim's distinct query (same serverurl) is served the attacker's cached response. Affected code Confirmed collisions (identical key): - { q: "budget", rows: 10 } ≡ { q: "budget&rows=10" } → both canonicalize to q=budget&rows=10 - { filters: { a: "b" } } ≡ { filters: '{"a":"b"}' } → both canonicalize to filters={"a":"b"} (object-vs-string ambiguity) An attacker can reproduce any target canonical string by injecting it into the alphabetically-first parameter, so the collision is general, not…
Recommended action: Upgrade to 0.4.112 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Error paths reflect raw upstream response bodies and internal exception messages back to the caller instead of a sanitized, generic message. When the server is pointed at (or redirected/SSRF'd to) a host that returns a non-CKAN response, or when an internal exception occurs, the caller receives verbatim upstream content and internal detail (hostnames, internal IPs, DB errors, stack fragments). Affected code src/utils/http.ts — the entire decoded upstream body is embedded in the thrown error, which formatCkanError returns to the tool result: src/worker.ts — the catch-all handler returns the raw Error.message in the JSON-RPC data field: Impact - Reflects arbitrary upstream response content to the caller. Combined with the SSRF vectors (advisories #01/#06), an attacker can use this as the read channel: point the server at an internal endpoint and receive its body inside the success=false error string (turning otherwise-blind SSRF into a semi-blind/return-value SSRF for any host…
Recommended action: Upgrade to 0.4.112 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The ckangetmqaquality and ckangetmqaqualitydetails tools restrict their serverurl argument to dati.gov.it via a regular expression. The regex is anchored only at the start and places no boundary after the host, so any URL whose host merely begins with dati.gov.it — or that uses dati.gov.it as URL userinfo before an @ — passes validation while actually targeting an attacker-controlled host. Affected code All of the following return true: | URL | Real host | |-----|-----------| | https://dati.gov.it.attacker.com/x | dati.gov.it.attacker.com (attacker) | | http://dati.gov.it.evil.example/api | dati.gov.it.evil.example (attacker) | | https://dati.gov.it@attacker.com/x | attacker.com (userinfo trick) | After passing this check, serverurl flows into getMqaQuality/getMqaQualityDetails, which call makeCkanRequest(serverUrl, "packageshow", { id }). The server therefore issues a request to the attacker-controlled host and returns its (parsed) response to the caller. Impact - The…
Recommended action: Upgrade to 0.4.112 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A known vulnerability CVE-2026-33060 indicated tools including ckanpackagesearch and sparqlquery that accept a baseurl parameter had the risk of making HTTP requests to arbitrary endpoints without restriction. A fix was applied to filter out ip addresses. However, a method to bypass exists. Details CKAN MCP Server validates caller-supplied CKAN server URLs by inspecting only the parsed hostname string before issuing outbound HTTP requests. In src/utils/http.ts, hostname aliases such as ip6-localhost are not equal to localhost, are not dotted IPv4 literals, and are not bracketed IPv6 literals, so they pass the SSRF filter but can resolve to loopback when the server performs the request. A remote MCP caller that can invoke CKAN tools with a serverurl can therefore make the server connect to local or private addresses and, for CKAN-shaped responses, receive response-derived data. Fix Replaced the single hostname === 'localhost' check with a blocked-hostname Set covering…
Recommended action: Upgrade to 0.4.106 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The @aborruso/ckan-mcp-server MCP server provides tools including ckanpackagesearch and sparqlquery that accept a baseurl parameter, making HTTP requests to arbitrary endpoints without restriction. A CKAN portal client has no legitimate reason to contact cloud metadata or internal network services. Severity Attack complexity is HIGH because exploitation requires prompt injection via malicious content (webpage, document) while the victim's AI assistant has this MCP server connected. Proof of Concept Tested inside Docker-in-Docker isolated environment with canary HTTP sidecar. Result: Canary received 9 HTTP requests. The high request volume confirms no rate limiting or URL validation. Root Cause No URL validation on baseurl parameter. No private IP blocking (RFC 1918, link-local 169.254.x.x), no cloud metadata blocking. The sparqlquery and ckandatastoresearchsql tools also accept arbitrary base URLs and expose injection surfaces. Impact Internal network scanning, cloud metadata…
Recommended action: Upgrade to 0.4.85 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.