CVE-2026-73846

GHSA-78x9-fhhx-v2g6 MEDIUM
Published September 3, 2026

## 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...

Full CISO analysis pending enrichment.

What systems are affected?

Package Ecosystem Vulnerable Range Patched
@aborruso/ckan-mcp-server npm < 0.4.112 0.4.112

Do you use @aborruso/ckan-mcp-server? You're affected.

How severe is it?

CVSS 3.1
6.5 / 10
EPSS
0.1%
chance of exploitation in 30 days
Higher than 3% of all CVEs
Exploitation Status
No known exploitation
Sophistication
N/A

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC High
PR None
UI None
S Unchanged
C Low
I High
A None

What should I do?

Patch available

Update @aborruso/ckan-mcp-server to version 0.4.112

Which compliance frameworks are affected?

Compliance analysis pending. Sign in for full compliance mapping when available.

Frequently Asked Questions

What is CVE-2026-73846?

## 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 ```js // 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 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 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.

Is CVE-2026-73846 actively exploited?

No confirmed active exploitation of CVE-2026-73846 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-73846?

Update to patched version: @aborruso/ckan-mcp-server 0.4.112.

What is the CVSS score for CVE-2026-73846?

CVE-2026-73846 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.14%.

What are the technical details?

Original Advisory

## 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 ```js // 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 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 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.

Weaknesses (CWE)

CWE-345 — Insufficient Verification of Data Authenticity: The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N

Timeline

Published
September 3, 2026
Last Modified
September 3, 2026
First Seen
September 3, 2026