A third CKAN MCP Server record: an unanchored allowlist regex let two quality tools be pointed at any host

GitHub assigned CVE-2026-73845 against the CKAN MCP Server on 2026-08-14, rating it 5.3 medium. Two of the server's tools, ckan_get_mqa_quality and ckan_get_mqa_quality_details, accept a server_url argument and are supposed to accept only Italy's national open-data portal at dati.gov.it. The check that enforced that, isValidMqaServer in src/tools/quality.ts, used a regular expression anchored only at the start.

An unanchored prefix match admits more than it looks like it does. A hostname that merely begins with the allowed string satisfies it, and so does a URL that carries the allowed string as userinfo before an @, where the real host is whatever follows. Either way the tools issue their request to a host the caller chose and hand back the response as though it were a quality assessment from the official portal. The record's framing is that the result is a spoofed response rather than credential-bearing access.

The fix shipped in 0.4.112 on 2026-07-09, five weeks before the record was assigned, and the project has since released through 0.4.119.

This is the third record against URL validation in the same server. The first, CVE-2026-33060, established an SSRF filter. The second, CVE-2026-53509, bypassed that filter through /etc/hosts aliases that passed a hostname-string check and resolved to loopback. This one is a different code path with the same shape: a string test standing in for a decision about where a request will actually go.

One note on how it reached us. The CVE was assigned 2026-08-14 but only appeared in the GitHub Advisory Database listing on 2026-09-02, which is why three sweeps in between did not see it. That is the same trap the PHP SDK advisory set in August, and it argues again for listing advisories unfiltered and deduplicating against existing coverage rather than filtering the query by publication window.