CVE-2026-31245

The mem0 1.0.0 server lacks authentication and authorization controls for its memory management API endpoints. Critical functions such as updating memory records are exposed without any verification of the requester's identity or permissions.

The openmemory/api component in mem0 contains an unauthenticated access vulnerability that allows unauthenticated attackers to read, write, and delete arbitrary user memories by accessing API routers registered without authentication middleware. Attackers can supply arbitrary user_id parameters or directly access memory retrieval endpoints to expose private memory content, or invoke pause endpoints with global_pause=true to cause denial-of-service across all users.

The vulnerability in mem0 exposes unauthenticated config API endpoints that disclose LLM API keys in plaintext and allow server-side request forgery (SSRF) via the attacker-controlled ollama_base_url parameter. Unauthenticated attackers can retrieve stored secrets like OpenAI API keys via GET /api/v1/config/ or trigger SSRF attacks by setting ollama_base_url to internal addresses such as cloud IMDS via PUT /api/v1/config/mem0/llm endpoint.

The mem0 v1.0.0 server lacks authentication and authorization controls for its memory reset functionality accessible via the DELETE /memories endpoint. An unauthenticated attacker can send a DELETE request that triggers a reset operation, leading to the execution of a DROP TABLE SQL statement.

Mem0, persistent memory infrastructure for AI agents, prior to Python SDK 2.0.18 and TypeScript SDK 3.1.6 joins caller-controlled user_id, agent_id and run_id values using unescaped & and = delimiters, allowing another scope component to be embedded in an identifier so distinct tenant tuples produce the same session_scope key. Memory.add(), AsyncMemory.add() and REST POST /memories use that key to read and save raw messages, enabling cross-tenant conversation disclosure and eviction or interleaving of another tenant's history.

mem0 0.1.117 before 1.0.8 contains an SQL injection vulnerability in mem0/vector_stores/databricks.py that allows attackers to inject SQL by influencing stored memory content. Attackers can supply crafted memory text, metadata, or message names that reach unescaped insert() and update() string interpolation to execute injected SQL on the configured Databricks SQL warehouse.

Mem0 versions up to 0.2.8 have a missing authorization vulnerability in the POST /configure endpoint. Any authenticated user with an API key can change global LLM and embedder configuration, redirecting all traffic to an attacker-controlled server. The malicious configuration persists in PostgreSQL and survives server restarts.

The mem0 1.0.0 server lacks authentication and authorization controls for its memory deletion API endpoint (DELETE /memories/{memory_id}). The endpoint allows unauthenticated users to delete arbitrary memory records without verifying identity or permissions. A remote attacker can send unauthenticated DELETE requests to remove any memory entry from the database, leading to unauthorized data loss and potential denial of service.

The mem0 1.0.0 server lacks authentication and authorization controls for its memory reset and table re-creation functionality accessible via the DELETE /memories endpoint. An unauthenticated attacker can send a DELETE request that triggers a reset operation, leading to the execution of a CREATE TABLE SQL statement.

The mem0 1.0.0 server lacks authentication and authorization controls for its memory deletion API endpoint (DELETE /memories). The endpoint allows unauthenticated users to delete memory records by specifying arbitrary user identifiers (e.g., user_id, run_id, agent_id) in the request query parameters. A remote attacker can send unauthenticated DELETE requests to erase memory data for any user, leading to unauthorized data loss and denial of service.