CVE-2026-73846: Cache Key Canonicalization Collision in ondata ckan-mcp-server

The ckan-mcp-server developed by ondata serves as an integration layer utilizing the Model Context Protocol (MCP) to query CKAN open data portals. To optimize retrieval latency and reduce backend load, the server implements a caching layer. This layer serializes request components to generate a deterministic cache key. A vulnerability exists in the serialization mechanism of versions prior to 0.4.112 which fails to safely isolate parameters, leading to cache collisions.

In standard deployments, caching engines rely on the uniqueness of cache keys to map user requests to stored responses. If two distinct requests generate the same cache key, the cache system cannot differentiate between them. This condition is known as a cache key collision. Under specific network and application states, it exposes the application to cache poisoning and unauthorized cache retrieval.

This flaw resides in the combination of the parameter serialization function canonicalizeParams and the main cache key generator buildCacheKey in src/utils/cache.ts. Because the application does not escape field delimiters or preserve data structure boundaries, external inputs can manipulate the logical interpretation of cache keys. This vulnerability represents a significant risk in environments serving sensitive, authenticated, or rate-limited open data.

The root cause of CVE-2026-73846 is an interpretation conflict (CWE-436) and insufficient verification of data authenticity (CWE-345) due to the unsafe concatenation of request boundaries. In the vulnerable implementation of canonicalizeParams, parameters are processed alphabetically and combined using standard URL-like delimiters. Specifically, key-value pairs are joined by the equals sign (=) and concatenated together using the ampersand (&) character.

The critical error is the absence of escaping or sanitization of these delimiter characters within the parameter values themselves. When a parameter value contains a literal & or =, the function processes it literally. This creates a structural ambiguity where the boundary between keys and values is lost during serialization. For example, a single parameter with a value containing an ampersand is serialized identically to two separate parameters.

Furthermore, the buildCacheKey function constructs the overall hash input by interpolating the server URL, action name, and serialized parameter string with a pipe delimiter (|). No escaping is applied to this delimiter either. An attacker capable of influencing the serverUrl or action string can shift boundaries across the three fields, leading to additional cache collision paths. Finally, the function does not differentiate between a nested object and its raw stringified equivalent, which creates another logical overlap vector.

To understand the exact mechanics, we examine the pre-patch code in src/utils/cache.ts.

// Pre-patch implementation of canonicalizeParams
export function canonicalizeParams(params: Record<string, unknown>): string {
  const keys = Object.keys(params).sort();
  const pairs: string[] = [];
  for (const key of keys) {
    const value = params[key];
    if (value === undefined || value === null) continue;
    const serialized =
      typeof value === "object" ? JSON.stringify(value) : String(value);
    pairs.push(`${key}=${serialized}`);
  }
  return pairs.join("&");
}

In this vulnerable implementation, if params is { q: 'budget&rows=10' }, the loop yields a single element q=budget&rows=10. If params is { q: 'budget', rows: 10 }, the sorted keys produce pairs ['q=budget', 'rows=10'], which when joined with & result in the exact same string: q=budget&rows=10. This lack of structural preservation directly results in identical SHA1 hashes after processing through buildCacheKey.

The patch in commit 8e1522f9bbfa1f3b21550f17887f60f133e24151 shifts the serialization model from string concatenation to structured JSON serialization. The updated implementation is shown below:

// Patched implementation utilizing JSON array wrapping
function canonicalizeValue(value: unknown): unknown {
  if (Array.isArray(value)) return value.map(canonicalizeValue);
  if (value && typeof value === "object") {
    const sorted: Record<string, unknown> = {};
    for (const key of Object.keys(value as Record<string, unknown>).sort()) {
      sorted[key] = canonicalizeValue((value as Record<string, unknown>)[key]);
    }
    return sorted;
  }
  return value;
}
 
export function canonicalizeParams(params: Record<string, unknown>): string {
  const filtered: Record<string, unknown> = {};
  for (const key of Object.keys(params)) {
    const value = params[key];
    if (value === undefined || value === null) continue;
    filtered[key] = value;
  }
  return JSON.stringify(canonicalizeValue(filtered));
}

In the patched code, parameters are filtered, recursively sorted by key to preserve order-independence, and then serialized via JSON.stringify(). This ensures that characters like & and = are safely wrapped in JSON string quotes and escaped, making serialization unique to the logical data structure. Additionally, buildCacheKey was modified to serialize its inputs within a JSON array, JSON.stringify([serverUrl, action, canonicalizeParams(params)]), eliminating the vulnerable | string interpolation.

Exploitation of this vulnerability requires an attacker to have network access to the MCP server to submit queries. The objective is to poison the cache for specific queries targeted at legitimate users. An attacker first identifies a target query that a victim is likely to make, such as querying a dataset for public budgets using specific row limits: { q: 'budget', rows: 10 }.

The attacker then sends a crafted query containing the injected delimiters within a single parameter: { q: 'budget&rows=10' }. The vulnerable server processes the attacker's query and serializes the parameter block to "q=budget&rows=10". The server then computes the SHA1 hash of the concatenated string and stores the attacker's customized response in the cache under that hash.

When the victim subsequently issues the legitimate request { q: 'budget', rows: 10 }, the server serializes the victim's parameters. Because of the delimiter collision, the victim's request serializes to the identical string "q=budget&rows=10". The caching layer generates the same SHA1 key, detects a cache hit, and returns the attacker-controlled cached response to the victim. This allows the attacker to forge query results, induce denial of service, or present manipulated information to users.

The technical impact of CVE-2026-73846 is classified as medium severity, with a CVSS v3.1 base score of 6.5. The attack vector is Network, and the attack complexity is High because successful exploitation depends on temporal factors, active cache states, and predicting or forcing user queries. There is no requirement for privileges or user interaction, making it accessible to external unauthenticated actors who can interact with the server.

The primary impact is on data integrity. Attackers can bind malicious, empty, or altered responses to legitimate parameters, causing users to receive incorrect data. While the direct confidentiality impact is rated as Low, cache confusion could potentially expose specific query outputs to unauthorized parties if the caching layer is shared across multiple security contexts.

According to EPSS data, the vulnerability has a low immediate probability of exploitation in the wild, with an EPSS score of 0.00137 (0.137% over 30 days). It is currently not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and there are no active, weaponized exploits publicly available. However, because MCP servers often act as bridges between LLMs (Large Language Models) and underlying data sources, a cache poisoning attack on an MCP server could corrupt the training data or prompt contexts of downstream AI systems.

The primary and recommended remediation is to upgrade ckan-mcp-server to version 0.4.112 or higher. The official patch fundamentally resolves the parsing ambiguity by adopting JSON-safe serialization. This ensures that parameter delimiters cannot break out of their structural boundaries.

If upgrading is not immediately feasible, organizations should implement input validation at the API gateway or proxy layer. Specifically, input filtering should block any incoming user queries that contain raw delimiter characters, such as &, =, or | within the values of parameters. This prevents attackers from submitting the boundary-breaking strings necessary to trigger the collision.

Additionally, if the environment allows, disabling caching entirely or reducing the cache Time-To-Live (TTL) to a minimal duration can reduce the window of opportunity for an attacker to exploit the timing constraints of cache poisoning. This should be combined with monitoring logs for anomalous query parameters that resemble serialized parameter strings.