GHSA-78X9-FHHX-V2G6
Vulnerability from github – Published: 2026-09-03 14:49 – Updated: 2026-09-03 14:49
VLAI
Summary
CKAN MCP Server: Cache-key canonicalization collision enables cache confusion / poisoning
Details
Summary
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 server_url) is served the attacker's cached response.
Affected code
// src/utils/cache.ts
export function canonicalizeParams(params) {
const keys = Object.keys(params).sort();
const pairs = [];
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}`); // value not escaped
}
return pairs.join("&"); // '&' delimiter, injectable
}
export async function buildCacheKey(serverUrl, action, params) {
const raw = `${serverUrl}|${action}|${canonicalizeParams(params)}`; // '|' also unescaped
return sha1Hex(raw);
}
Confirmed collisions (identical key):
{ q: "budget", rows: 10 }≡{ q: "budget&rows=10" }→ both canonicalize toq=budget&rows=10{ filters: { a: "b" } }≡{ filters: '{"a":"b"}' }→ both canonicalize tofilters={"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 incidental.
Impact
- Cache poisoning / confusion. On a shared cache (caching is enabled by
default; the Cloudflare Workers deployment uses the shared
caches.default, and a Node HTTP instance shares one in-process LRU across all clients), an attacker primes a colliding entry so that another client's genuinely different query receives the attacker-chosen response for the same portal. - Integrity of results. Victims receive data for a query they did not make (wrong dataset list, wrong record set), undermining trust in tool output.
- Chains with indirect prompt injection (advisory #07). The attacker's
colliding request can be one whose upstream response surfaces an
attacker-controlled dataset (with malicious
notes/title); the victim's benign query then serves that poisoned content to the model — delivering prompt injection via the cache, without the victim ever querying the malicious dataset.
Confidentiality impact is low (same-portal public data); the primary damage is
integrity. AC:H reflects the need for caching to be enabled and a shared
instance plus priming before the victim's request populates the entry.
Proof of concept
poc/cache-collision-poc.mjs primes a single-param request and shows a victim's
distinct two-param request being served the attacker-primed entry:
attacker canonical : q=budget&rows=10
victim canonical : q=budget&rows=10
same cache key : true
victim served from cache: true
victim RECEIVED : RESULT_FOR({"q":"budget&rows=10"})
victim EXPECTED : RESULT_FOR({"q":"budget","rows":10})
Remediation
- Build the cache key from an unambiguous, injection-proof encoding: hash a
structured, canonical JSON (with typed values) or percent-encode/escape each key
and value before joining, and use a separator that cannot appear in the encoded
fields. Include a type tag so
{a:{...}}(object) and{a:"..."}(string) never coincide. - Consider partitioning the cache per client/tenant on shared deployments so one client cannot influence another's entries.
Severity
6.5 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@aborruso/ckan-mcp-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.4.112"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-73846"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-436"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-03T14:49:22Z",
"nvd_published_at": "2026-08-14T17:20:36Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nThe response cache derives its key from an ambiguous string serialization of the request parameters. `canonicalizeParams` joins sorted `${key}=${value}` pairs with `\u0026` and does not escape `\u0026`, `=`, 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\u0027s distinct query (same `server_url`) is served the attacker\u0027s cached response.\n\n## Affected code\n\n```js\n// src/utils/cache.ts\nexport function canonicalizeParams(params) {\n const keys = Object.keys(params).sort();\n const pairs = [];\n for (const key of keys) {\n const value = params[key];\n if (value === undefined || value === null) continue;\n const serialized = typeof value === \"object\" ? JSON.stringify(value) : String(value);\n pairs.push(`${key}=${serialized}`); // value not escaped\n }\n return pairs.join(\"\u0026\"); // \u0027\u0026\u0027 delimiter, injectable\n}\n\nexport async function buildCacheKey(serverUrl, action, params) {\n const raw = `${serverUrl}|${action}|${canonicalizeParams(params)}`; // \u0027|\u0027 also unescaped\n return sha1Hex(raw);\n}\n```\n\nConfirmed collisions (identical key):\n\n- `{ q: \"budget\", rows: 10 }` \u2261 `{ q: \"budget\u0026rows=10\" }` \u2192 both canonicalize to `q=budget\u0026rows=10`\n- `{ filters: { a: \"b\" } }` \u2261 `{ filters: \u0027{\"a\":\"b\"}\u0027 }` \u2192 both canonicalize to `filters={\"a\":\"b\"}` (object-vs-string ambiguity)\n\nAn attacker can reproduce **any** target canonical string by injecting it into the alphabetically-first parameter, so the collision is general, not incidental.\n\n## Impact\n\n- **Cache poisoning / confusion.** On a shared cache (caching is enabled by\n default; the Cloudflare Workers deployment uses the shared `caches.default`, and\n a Node HTTP instance shares one in-process LRU across all clients), an attacker\n primes a colliding entry so that another client\u0027s genuinely different query\n receives the attacker-chosen response for the same portal.\n- **Integrity of results.** Victims receive data for a query they did not make\n (wrong dataset list, wrong record set), undermining trust in tool output.\n- **Chains with indirect prompt injection (advisory #07).** The attacker\u0027s\n colliding request can be one whose upstream response surfaces an\n attacker-controlled dataset (with malicious `notes`/`title`); the victim\u0027s\n benign query then serves that poisoned content to the model \u2014 delivering prompt\n injection via the cache, without the victim ever querying the malicious dataset.\n\nConfidentiality impact is low (same-portal public data); the primary damage is\nintegrity. `AC:H` reflects the need for caching to be enabled and a shared\ninstance plus priming before the victim\u0027s request populates the entry.\n\n## Proof of concept\n\n`poc/cache-collision-poc.mjs` primes a single-param request and shows a victim\u0027s\ndistinct two-param request being served the attacker-primed entry:\n\n```\nattacker canonical : q=budget\u0026rows=10\nvictim canonical : q=budget\u0026rows=10\nsame cache key : true\nvictim served from cache: true\nvictim RECEIVED : RESULT_FOR({\"q\":\"budget\u0026rows=10\"})\nvictim EXPECTED : RESULT_FOR({\"q\":\"budget\",\"rows\":10})\n```\n\n## Remediation\n\n- Build the cache key from an unambiguous, injection-proof encoding: hash a\n structured, canonical JSON (with typed values) or percent-encode/escape each key\n and value before joining, and use a separator that cannot appear in the encoded\n fields. Include a type tag so `{a:{...}}` (object) and `{a:\"...\"}` (string)\n never coincide.\n- Consider partitioning the cache per client/tenant on shared deployments so one\n client cannot influence another\u0027s entries.",
"id": "GHSA-78x9-fhhx-v2g6",
"modified": "2026-09-03T14:49:22Z",
"published": "2026-09-03T14:49:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ondata/ckan-mcp-server/security/advisories/GHSA-78x9-fhhx-v2g6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73846"
},
{
"type": "WEB",
"url": "https://github.com/ondata/ckan-mcp-server/commit/8e1522f9bbfa1f3b21550f17887f60f133e24151"
},
{
"type": "PACKAGE",
"url": "https://github.com/ondata/ckan-mcp-server"
},
{
"type": "WEB",
"url": "https://github.com/ondata/ckan-mcp-server/releases/tag/v0.4.112"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "CKAN MCP Server: Cache-key canonicalization collision enables cache confusion / poisoning"
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
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.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
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.
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.
Loading…
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.