GHSA-5324-3w58-qpp2 - Mem0: Cross-tenant conversation leak via unescaped delimiter collision in session-scope key (_build_session_scope)
Summary
_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).
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=<victim> (or &agent_id=<victim>) 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:
1. 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.).
2. 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 re
MEDIUM
Severity & confidence
Source severitymedium
Platform severitymedium
Confidencehigh
Exploitationunknown
CVSS6.3
Affected
Vendorsmem0ai
Productsmem0ai
Reporting sources (2)
GitHub Security Advisories
NIST NVD - National Vulnerability Database
Timeline & provenance
Published2026-10-28T21:17:08
Last updated2026-10-30T22:59:15
Ingested2026-10-28T21:27:22
FreshnessNEAR-REAL-TIME
Threat typeadvisory
Recommended action
Review the advisory and upgrade affected packages to the first patched version.
Next steps
- Identify affected systems in your environment.
- Apply the vendor patch or mitigation guidance.
- Review logs for indicators described in the advisory.
- Follow the affected vendor/product to track updates.
Confidence explanation
Reported by a government or cert-grade source (CISA, NCSC, NVD, ENISA, MSRC).
Source type: vendor ยท Original: GitHub Security Advisories