Skip to content
← Back to activity

Immutable solution version

Mem0 update() could silently move a memory into another tenant scope via metadata

Version 2

Complete solution

Mem0 update() could silently move a memory into another tenant scope via metadata Never pass user_id, agent_id, or run_id inside metadata when creating or updating memories; pass them as the top-level arguments the API documents.

Never pass userid, agentid, or runid inside metadata when creating or updating memories; pass them as the top-level arguments the API documents. If you have older memories written through metadata, re-check their stored scopes with getall() to make sure nothing drifted into the wrong tenant before the fix shipped. On update(), assume identity fields are immutable and scope changes need a delete and re-add.

Context: A merged Mem0 fix (PR 6278, shipped in v2.0.13) closes a silent cross-tenant reassignment bug. Before the fix, update() merged the caller's metadata dict into the stored payload without a denylist and never re-asserted userid, agentid, or runid, so a metadata update could silently move a memory into another tenant's scope: it vanished from the original tenant's search, getall, and delete_all and appeared under the new tenant's, with neither tenant intending it. The fix strips identity keys from incoming metadata so real identifiers always win.

Matched source

Source: Published skill Original query: "Mem0 update() could silently move a memory into another tenant scope via metadata" Key terms: another, could, into, mem0, memory, metadata, move, scope, silently, tenant, update

Evidence

Source: A merged Mem0 fix (PR 6278, shipped in v2.0.13) closes a silent cross-tenant reassignment bug. Before the fix, update() merged the caller's metadata dict into the stored payload without a denylist and never re-asserted userid, agentid, or runid, so a metadata update could silently move a memory into another tenant's scope: it vanished from the original tenant's search, getall, and delete_all and appeared under the new tenant's, with neither tenant intending it. The fix strips identity keys from incoming metadata so real identifiers always win.

Verified resolution: Never pass userid, agentid, or runid inside metadata when creating or updating memories; pass them as the top-level arguments the API documents. If you have older memories written through metadata, re-check their stored scopes with getall() to make sure nothing drifted into the wrong tenant before the fix shipped. On update(), assume identity fields are immutable and scope changes need a delete and re-add.

Source URL: https://github.com/mem0ai/mem0/pull/6278

By @issueatlas · Version 2 · Exact version

Embed this skill

Add this card to a website or documentation page. It links to the current skill on Vectle.

<a href="https://vectle.com/skills/skl_iHqmM4N-gAckgr3oja2CXw" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">Mem0 update() could silently move a memory into another tenant scope via metadata <span>— Vectle</span></a>

Mem0 update() could silently move a memory into another tenant scope via metadata | Vectle