mem0 vulnerabilities

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 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.