Mem0 EUVD-2026-110315

Requires a multi-tenant Mem0 deployment that uses the recent-conversation buffer and passes a caller-/client-supplied identifier straight through as run_id (or agent_id) without server-side namespacing - the common integration shape called out in the advisory. The attacker must be a legitimate caller of Memory.add()/AsyncMemory.add() or the REST 'POST /memories' endpoint, and must know the victim tenant's exact user_id and run_id/agent_id values in order to craft an identifier embedding '&user_id=<victim>' that collides on the session_scope key. Limiting factors: no exploitation is possible against single-tenant usage or where ids are server-assigned/namespaced; the attack needs prior knowledge of victim identifiers (reflected as high attack complexity) and low-privileged caller access; only the last-N raw-message conversation buffer is exposed, while stored memories are unaffected.

Signals point consistently to a real but non-emergency, conditionally-exploitable issue rather than a top priority. The CVSS vector (AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N, base 6.3) describes a privileged, high-complexity attack with serious confidentiality and integrity impact - consistent with the mechanism, where a low-privileged tenant must already be a legitimate caller and must know the victim's exact identifier values to forge a colliding session_scope key. EPSS is very low (0.11%, 1st percentile) and the vulnerability is NOT in CISA KEV, so there is no evidence of active or widespread exploitation; the low EPSS is consistent with an abuse that requires multi-tenant deployment plus knowledge of victim identifiers rather than spray-and-pray scanning. The vuln.today decision label is 'this_month', indicating prioritized but not urgent remediation. No SSVC decision tuple (exploitation/automatable/technical impact) was supplied, so that framework cannot be cross-referenced. One notable tension: the vendor vector uses AV:L, but the advisory explicitly lists the REST 'POST /memories' endpoint (which reads run_id/agent_id straight from the request body) as a reachable path, which would be network-reachable - verify the intended attack vector against your deployment (library-embedded vs. exposed REST server). Overall this is a genuine cross-tenant isolation flaw worth patching, but the required preconditions and absent exploitation evidence keep real-world risk moderate rather than critical.

In a multi-tenant app that passes a client-supplied session identifier straight through as run_id, an attacker who controls only their own run_id sets it to a value such as 'proj-x&user_id=alice', producing a session_scope string byte-for-byte identical to victim 'alice'. The attacker's next add() call then reads alice's prior raw conversation (potentially PII/credentials) into the attacker's own fact-extraction prompt and can evict or interleave alice's stored history. A collision reproduction snippet is published in the GHSA advisory, and the reporter states a full end-to-end proof exists (offered on request) but is not published, so this is not verified as working public exploit code; high attack complexity reflects the need to know the victim's exact identifier values.