CKAN MCP server UI panel accepts messages from any origin

A security advisory published on 16 October 2026 describes a flaw in the npm package @aborruso/ckan-mcp-server, a Model Context Protocol server for querying CKAN open data portals. The advisory, tracked as GHSA-vqff-r82h-9crc and CVE-2026-76894, says the package's interactive DataStore table — an HTML panel rendered inside the host application's webview or iframe — exchanges messages with its parent window without any origin checks. The advisory rates the issue Low.

According to the advisory, the problem sits in the inline HTML inside src/resources/datastore-table-ui.ts. The panel registers a listener for browser postMessage events, which let one frame send data to another, but it never inspects event.origin to confirm who sent the message. Messages that contain a fields or records object are passed straight to the function that draws the table. Outbound messages run the same risk in reverse: the panel sends its JSON-RPC traffic to window.parent with a target origin of '*', meaning any parent is accepted as a recipient.

The advisory lists three consequences. The first is content spoofing. A frame that can reach the document can supply arbitrary rows and links, so the table renders fabricated data that appears to have come from the queried CKAN portal, including a phishing URL in the __link_url field. The advisory is explicit that values are HTML-escaped, so this is display spoofing rather than cross-site scripting.

The second is interference with the MCP Apps handshake. Because inbound messages carrying a matching request id resolve or reject the panel's pending MCP requests, an attacker frame can forge a reply to the ui/initialize handshake or otherwise disrupt the panel, the advisory says.

The third is outbound leakage. With a target origin of '*', the panel's JSON-RPC messages go to whatever the parent origin happens to be. If the resource is ever embedded by something other than the trusted host, those messages are handed to that embedder.

The advisory includes two proof-of-concept artefacts. One, poc/verify-no-origin-check.mjs, is a static check that reports no origin validation on the listener and a wildcard target origin on outbound calls, returning the verdict "VULNERABLE". The other, poc/parent-spoof-poc.html, is a page that embeds the panel and injects fabricated rows cross-origin without performing the handshake; the advisory says the panel renders them.

The advisory explains why the severity is set low. Exploitability depends on how the host embeds the panel, and in a correctly implemented MCP Apps host the parent is the trusted host itself, which limits who can message the frame. On that basis the advisory describes the issue as a hardening and defence-in-depth problem rather than one that can be triggered remotely on demand.

For remediation, the advisory recommends validating event.origin against the expected host origin on every inbound message and discarding anything else, and sending outbound messages with an explicit target origin established at initialise time rather than '*'. It also suggests an optional measure: binding the channel to a nonce agreed during ui/initialize, so only the negotiated host can drive the panel.