Mem0 memory keys can be forged to read other tenants' chats

A vulnerability disclosed on 28 October 2026 in Mem0, the open-source memory layer for AI agents, lets an attacker read and overwrite another tenant's raw conversation history by stuffing delimiter characters into an identifier they already control. The flaw is tracked as CVE-2026-116575 and covered by GitHub advisory GHSA-5324-3w58-qpp2, which lists both the Python package mem0ai and the npm package of the same name as affected.

According to the advisory, the problem sits in _build_session_scope() in mem0/memory/main.py. That function builds the key used to fetch and store the last raw messages for a session. It does so by joining caller-supplied user_id, agent_id and run_id values into a single string using unescaped & and = characters, in the style of a URL query string. The only validation applied to those values, _validate_and_trim_entity_id(), rejects empty or whitespace-only strings and nothing else. It never forbids & or =.

The resulting string is used as an exact-match key against a SQLite column to pull back the last ten raw messages for that scope. Because the separators are not escaped, two different sets of identifiers can produce the same key. The advisory gives a worked example: a tenant calling add() with user_id="alice" and run_id="proj-x" produces the scope run_id=proj-x&user_id=alice. An attacker who can set only run_id passes the value proj-x&user_id=alice and produces a byte-for-byte identical scope string.

The advisory describes two consequences. First, the attacker's next add() call reads the victim's prior raw conversation through get_last_messages() and splices it verbatim into the attacker's own fact-extraction prompt sent to the language model, which the advisory calls a direct cross-tenant confidentiality leak that could include personal data or credentials. Second, the attacker writes into the same colliding set of rows through save_messages(), whose eviction logic deletes older rows matching the scope. That can evict or interleave the victim's history, which the advisory describes as permanent cross-tenant data corruption rather than a read-only issue.

The advisory says the flaw is reachable through the public Memory.add() and AsyncMemory.add() interfaces, and by extension through the REST server's POST /memories endpoint, which takes run_id and agent_id straight from the request body. It notes that passing a client- or session-supplied identifier directly through as run_id without namespacing is a common integration pattern.

The same construction appears in the TypeScript SDK, in Memory.buildSessionScope(), which joins the same three fields into the same unescaped key=value&key=value string and uses it the same way against the messages table. The advisory says the forge, the cross-tenant read and the eviction all apply there too. It states that the unescaped join was verified as present in pip mem0ai v2.0.14 and npm mem0ai ts-v3.1.2 as of 26 July 2026.

The suggested fix in the advisory is to reject & and = inside _validate_and_trim_entity_id(), which it describes as the single validation chokepoint already used by add, search, get_all and delete_all. As an alternative or addition, it recommends encoding each component unambiguously, for example by percent-encoding each identifier or using a length-prefixed or JSON-encoded scope key, so that no combination of valid characters in one field can collide with another partition. The advisory credits the report to Abhinav Singh.