Unauthenticated Memory Access in mem0 API

Executive Summary

The vulnerability exists in mem0's openmemory/api component, where certain API routers are registered without authentication middleware. This allows unauthenticated attackers to read, write, and delete arbitrary user memories by supplying arbitrary user_id parameters or directly accessing memory retrieval endpoints.

Additionally, attackers can invoke pause endpoints with a global_pause=true parameter, causing a denial-of-service condition that affects all users.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can have severe impacts including unauthorized access to private user memories, modification or deletion of user data, and disruption of service for all users through denial-of-service attacks.

Useful 0 Not Useful 0

Compliance Impact

The vulnerability allows unauthenticated attackers to read, write, and delete arbitrary user memories, exposing private memory content and causing denial-of-service. This unauthorized access to private user data and disruption of service could lead to violations of data protection regulations such as GDPR and HIPAA, which require strict controls on access to personal and sensitive information.

Specifically, the exposure of private memory content compromises confidentiality requirements, while the ability to modify or delete data affects integrity and availability, all of which are critical components of compliance with these standards.

Useful 0 Not Useful 0

Detection Guidance

The vulnerability can be detected by checking for unauthenticated access to the openmemory/api endpoints that allow reading, writing, or deleting user memories without authentication.

Specifically, you can test if the API routers accept requests without authentication middleware and if supplying arbitrary user_id parameters returns or modifies memory data.

Commands to detect this might include sending HTTP requests to the memory retrieval endpoints or pause endpoints without authentication headers and observing if private data is returned or if denial-of-service can be triggered.

• Use curl or similar tools to send GET requests to memory retrieval endpoints with arbitrary user_id parameters, e.g.: curl -X GET "https://<target>/openmemory/api/get_memory?user_id=some_id&memory_uuid=<uuid>"
• Send POST or DELETE requests to update or delete endpoints without authentication to check if operations succeed.
• Invoke the pause endpoint with the parameter global_pause=true to test if denial-of-service can be triggered: curl -X POST "https://<target>/openmemory/api/pause?global_pause=true"

Useful 0 Not Useful 0

Mitigation Strategies

Immediate mitigation steps include adding authentication mechanisms to all openmemory/api routers to prevent unauthenticated access.

Implement ownership verification in each API handler to ensure that the authenticated user matches the owner of the memory being accessed or modified.

• Add API key, JWT, or session token authentication middleware to all API endpoints.
• Validate user_id parameters against the authenticated user's identity before processing requests.
• Restrict or disable the pause endpoint or require strict authentication and authorization checks before allowing global_pause=true.

These steps will prevent unauthorized reading, writing, deleting of memories, and denial-of-service attacks caused by this vulnerability.

Useful 0 Not Useful 0