Skip to content
AI Security Wire

Published

- 4 min read

By

Mem0 Cross-Tenant Leak: Delimiter Collision in Session Keys (CVE-2026-116575)

Mem0 CVE-2026-116575 agent memory multi-tenant GHSA-5324-3w58-qpp2
img of Mem0 Cross-Tenant Leak: Delimiter Collision in Session Keys (CVE-2026-116575)

A GitHub advisory published on October 28, 2026 describes a cross-tenant data leak in Mem0, an Apache-2.0 open-source memory layer for AI agents (NVD calls it “persistent memory infrastructure for AI agents and applications”). It is tracked as CVE-2026-116575 (GHSA-5324-3w58-qpp2). The bug is not exotic. It is a string-building mistake in the key that decides whose conversation history gets loaded into the model’s prompt.

If you are running an agent memory layer, this is worth ten minutes. We have covered how memory can be poisoned. This one is about memory being shared by accident.

What the advisory says

Mem0 keeps the last few raw messages for each conversation in a SQLite table, keyed by a “session scope” string. Per the advisory, _build_session_scope() builds that string by joining user_id, agent_id and run_id as key=value pairs separated by &. Per the advisory, the only validation on those IDs rejects empty or whitespace-only values. It does not forbid & or =.

So a caller who controls only their own run_id can send proj-x&user_id=alice. That produces the same scope string as a genuine request with run_id set to proj-x and user_id set to alice. The advisory shows both strings and says an end-to-end test with real add() calls confirmed the collision.

What an attacker gets

Two things, according to the advisory. First, a read: the attacker’s next add() call fetches the victim’s recent raw messages and splices them into the attacker’s own fact-extraction prompt. Second, a write: saving messages under the forged scope can evict or interleave the victim’s history, which the advisory calls permanent cross-tenant corruption.

The advisory says the path is reachable through the public Memory.add() and AsyncMemory.add() APIs, and, the advisory infers, through the REST server’s POST /memories endpoint, which takes run_id and agent_id from the request body. The TypeScript SDK has the same unescaped join in buildSessionScope().

The condition that matters is in the advisory’s own wording: apps that pass a client-supplied or session-supplied identifier straight through as run_id, without namespacing it. Our assessment: if your backend generates every ID itself, the attacker has nothing to inject. Note the precondition too: the attacker must know or guess the victim’s ID to embed it.

Scoring and status

GitHub rates it 6.3, medium (CVSS 3.1, AV:L/AC:H/PR:L, high confidentiality and integrity impact, CWE-200 and CWE-863). That is GitHub’s score as CNA; NVD labels it secondary, and the NVD record is Deferred with no NVD-primary score as of October 30. A CISA coordinator SSVC entry from October 27 says exploitation none, automatable no, technical impact total.

One thing we noticed: the vector is AV:L, yet the advisory also describes a REST endpoint, and the advisory does not explain the scoring. The advisory covers the open-source packages only and says nothing about Mem0’s hosted platform. Judge your own exposure by how IDs reach a self-hosted Mem0.

No evidence of exploitation found as of October 30, 2026 in the CISA KEV feed released October 29 or in the advisory text.

The timing

The fix is not new. PyPI shows mem0ai 2.0.18 uploaded on August 11, 2026, and npm shows 3.1.6 published the same day. The advisory went out 78 days later. That is a fact about release and publication dates. The advisory does not say when the maintainers learned of the bug, and the advisory text says the reporter checked releases as of July 26 (Python 2.0.14, npm 3.1.2). Current releases are 2.2.1 on PyPI and 3.3.1 on npm, so anyone who updates on a normal cadence may already be patched.

What to do

  1. Upgrade mem0ai to 2.0.18 or later (Python) or 3.1.6 or later (npm).
  2. Check where run_id, agent_id and user_id come from. Never pass a client-supplied value through unchanged. The advisory suggested rejecting & and = or encoding each component; per the v2.0.18 and ts-v3.1.6 release notes, the shipped fix percent-escapes %, & and =. A side effect is that an ID already containing those characters maps to a new key, so its recent-conversation buffer starts empty once and refills on the next add().
  3. If you ran an affected version with client-controlled IDs, treat stored conversation history as potentially read by another tenant. Our suggestion: review logs for run_id values containing &user_id= or &agent_id=.
  4. Test tenant isolation at the memory layer, not only at your API gateway.

References

Frequently Asked Questions

Which Mem0 versions are affected and what fixes it?
Per GHSA-5324-3w58-qpp2, the Python package mem0ai is affected before 2.0.18 and the npm package mem0ai before 3.1.6. Upgrading to those versions or later is the fix. PyPI and npm list both fixed releases as published on August 11, 2026.
Is CVE-2026-116575 being exploited?
No evidence of exploitation found as of October 30, 2026 in the CISA KEV JSON feed (released 2026-10-29T19:09Z) or in the advisory text. A CISA coordinator SSVC entry in NVD, dated October 27, lists exploitation as none. That is a point-in-time record, not a guarantee.
How severe is it?
GitHub, acting as CNA, scores it 6.3 (medium) with a local attack vector and high attack complexity. NVD lists the record as Deferred and carries only that secondary score. The same SSVC entry rates technical impact as total. Our assessment: the real risk depends on whether your app passes client-supplied IDs into Mem0.