mem0ai/mem0

Mem0 versions through 0.2.8, fixed in commit ae7f406, contain a missing authorization vulnerability in the self-hosted server component where the POST /configure endpoint modifies global LLM provider and embedder configuration but only verifies authentication via JWT or X-API-Key without validating the caller's role. Any authenticated user holding a distributed API key can redirect all LLM and embedder traffic to an attacker-controlled server, with the malicious configuration persisted to PostgreSQL and surviving server restarts to affect all users and API keys on the instance.

The mem0 1.0.0 server lacks authentication and authorization controls for its memory creation API endpoint (POST /memories). The endpoint allows unauthenticated users to submit arbitrary memory records without verifying their identity or permissions. A remote attacker can exploit this by sending unauthenticated POST requests to create malicious or spoofed memory entries in the database, leading to unauthorized data injection and potential data pollution.

The mem0 1.0.0 server lacks authentication and authorization controls for its memory management API endpoints. Critical functions such as updating memory records (PUT /memories/{memory_id}) are exposed without any verification of the requester's identity or permissions. A remote attacker can exploit this by sending unauthenticated requests to modify, overwrite, or delete arbitrary memory records, leading to unauthorized data manipulation and potential data loss.

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 exploit this by sending unauthenticated DELETE requests to erase memory data for any user, leading to unauthorized data loss and denial of service.

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. This results in the deletion of the entire memory database table, causing catastrophic data loss and a complete denial of service for all users of the 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. This can cause unexpected table re-creation, schema disruption, potential data loss, and denial of service for the memory management service.

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 their identity or permissions. A remote attacker can exploit this by sending unauthenticated DELETE requests to remove any memory entry from the database, leading to unauthorized data loss and potential denial of service.

A vulnerability was found in mem0ai mem0 up to 1.0.11. This affects the function pickle.load/pickle.dump of the file mem0/vector_stores/faiss.py. Performing a manipulation results in deserialization. It is possible to initiate the attack remotely. The exploit has been made public and could be used. The patch is named 62dca096f9236010ca15fea9ba369ba740b86b7a. Applying a patch is the recommended action to fix this issue.

The OpenAPI loader in Embedchain before 0.1.57 allows attackers to execute arbitrary code, related to the openapi.py yaml.load function argument.

The JSON loader in Embedchain before 0.1.57 allows a ReDoS (regular expression denial of service) via a long string to json.py.