Summary
Mem0: Cross-tenant conversation leak via unescaped delimiter collision in session-scope key (buildsession_scope)
_build_session_scope() in mem0/memory/main.py builds the conversation-history scope key used to fetch/store the last N raw messages by naively joining caller-supplied user_id/agent_id/run_id values with unescaped & and = delimiters:
def _build_session_scope(filters):
parts = []
for key in sorted(["user_id", "agent_id", "run_id"]):
val = filters.get(key)
if val:
parts.append(f"{key}={val}")
return "&".join(parts)
_validate_and_trim_entity_id() (the only validation applied to these values) rejects only empty/whitespace-only strings, it never forbids & or =. This scope string is then used as an exact-match key against a SQLite column (storage.py: WHERE session_scope = ?) to fetch the last 10 raw messages for a given scope (main.py, Phase 0 of _add_to_vector_store, both sync and async).
Reproduction
from mem0.memory.main import _build_session_scope
Tenant A: real user_id + run_id
scope_a = _build_session_scope({"user_id": "alice", "run_id": "proj-x"})
print(scope_a) # "run_id=proj-x&user_id=alice"
Attacker: controls only run_id, embeds a fake user_id inside it
scope_c = _build_session_scope({"run_id": "proj-x&user_id=alice"})
print(scope_c) # "run_id=proj-x&user_id=alice"
assert scope_a == scope_c # byte-for-byte collision
A full end-to-end proof (actual add() calls, no mocking of the vulnerable functions) confirms the attacker's subsequent add() call receives the victim's raw prior message content via get_last_messages.
Impact
Any caller who controls only their own run_id (or agent_id), a very common integration shape, since apps frequently pass a client-/session-supplied identifier straight through as run_id without namespacing, can craft a value containing &user_id= (or &agent_id=) that produces a scope string byte-for-byte identical to a different tenant's real scope string.
Concretely: Tenant A calls add(msgs, user_id="alice", run_id="proj-x") → scope "run_id=proj-x&user_id=alice". An attacker who can only set run_id calls add(msgs, run_id="proj-x&user_id=alice") → identical scope string. The attacker's next add() call:
- Reads Tenant A's raw prior conversation via get_last_messages(session_scope) and splices it verbatim into the attacker's own LLM fact-extraction prompt, a direct cross-tenant confidentiality leak (conversation content, potentially including PII, credentials, etc.).
- Writes into the same colliding row-set via save_messages(), whose eviction logic (DELETE FROM messages WHERE session_scope = ? AND id NOT IN (...)) can evict/interleave Tenant A's history, permanent cross-tenant data corruption, not just a read.
Reachable via the public Memory.add() / AsyncMemory.add() API, and by extension the REST server's POST /memories endpoint (which takes run_id/agent_id straight from the request body).
The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions. Typical impact: unauthorized data access or execution of privileged operations.
CVE-2026-116575 has a CVSS score of 6.3 (Medium). The vector is requires local access, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.0.18, 3.1.6); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Reject & and = in _validate_and_trim_entity_id(), alongside the existing whitespace check, this is the single validation chokepoint already used by every entry point (add, search, get_all, delete_all), so the fix is centralized. Alternatively/additionally, encode each component unambiguously (percent-encode each id, or use a length-prefixed/JSON-encoded scope key) so no valid-character combination in one field can ever collide with a different partition.
Also affected: TypeScript SDK (npm mem0ai)
The same flaw exists in mem0-ts/src/oss/src/memory/index.ts,
Memory.buildSessionScope(), which joins agent_id/run_id/user_id into the samekey=value&key=value string with the delimiters unescaped:
private buildSessionScope(filters: SearchFilters): string {
const parts: string[] = [];
for (const key of ["agent_id", "run_id", "user_id"].sort()) {
const val = (filters as any)[key];
if (val) parts.push(${key}=${val});
}
return parts.join("&");
}
The scope string is used the same way, as an exact-match key into the messages
table via SQLiteManager.getLastMessages() and saveMessages(), so the identical
forge, cross-tenant read and eviction all apply.
Verified against the current releases as of 2026-07-26: pip mem0ai v2.0.14 and
npm mem0ai ts-v3.1.2 both still contain the unescaped join.
Reporter: Abhinav Singh (GitHub: OfficialAbhinavSingh)
Frequently Asked Questions
- What is CVE-2026-116575? CVE-2026-116575 is a medium-severity incorrect authorization vulnerability in mem0ai (pip), affecting versions < 2.0.18. It is fixed in 2.0.18, 3.1.6. The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions.
- How severe is CVE-2026-116575? CVE-2026-116575 has a CVSS score of 6.3 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of mem0ai are affected by CVE-2026-116575? mem0ai (pip) versions < 2.0.18 is affected.
- Is there a fix for CVE-2026-116575? Yes. CVE-2026-116575 is fixed in 2.0.18, 3.1.6. Upgrade to this version or later.
- Is CVE-2026-116575 exploitable, and should I be worried? Whether CVE-2026-116575 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-116575 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-116575?
- Upgrade
mem0aito 2.0.18 or later - Upgrade
mem0aito 3.1.6 or later
- Upgrade