<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-04T07:59:03.756220+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/fkie_cve-2026-73846</id>
    <title>fkie_cve-2026-73846</title>
    <updated>2026-10-04T07:59:03.757969+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>CKAN MCP Server is a tool for querying CKAN open data portals. Prior to 0.4.112, canonicalizeParams in src/utils/cache.ts serializes request parameters with unescaped ampersand, equals-sign, and vertical-bar delimiters, allowing different logical parameter sets used by buildCacheKey to collide and an attacker to prime a shared cache with a response for a victim's distinct query. This issue is fixed in version 0.4.112.</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-73846"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-78x9-fhhx-v2g6</id>
    <title>GHSA-78x9-fhhx-v2g6 — CKAN MCP Server: Cache-key canonicalization collision enables cache confusion / poisoning</title>
    <updated>2026-10-04T07:59:03.758073+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> npm: @aborruso/ckan-mcp-server</p>
<p>## Summary</p>
<p>The response cache derives its key from an ambiguous string serialization of the request parameters. `canonicalizeParams` joins sorted `${key}=${value}` pairs with `&amp;` and does not escape `&amp;`, `=`, 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.</p>
<p>## Affected code</p>
<p>```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("&amp;");                        // '&amp;' delimiter, injectable
}</p>
<p>export async function buildCacheKey(serverUrl, action, params) {
  const raw = `${serverUrl}|${action}|${canonicalizeParams(params)}`;  // '|' also unescaped
  return sha1Hex(raw);
}
```</p>
<p>Confirmed collisions (identical key):</p>
<p>- `{ q: "budget", rows: 10 }`  ≡  `{ q: "budget&amp;rows=10" }`  → both canonicalize to `q=budget&amp;rows=10`
- `{ filters: { a: "b" } }`  ≡  `{ filters:…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-78x9-fhhx-v2g6"/>
  </entry>
</feed>
