EUVD-2026-29564
GHSA-gq6f-qwv9-rf4j
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
Primary rating from NVD · only source for this CVE.
CVSS VectorNVD
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
Lifecycle Timeline
4DescriptionCVE.org
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.
AnalysisAI
mem0 1.0.0 server exposes an unauthenticated memory deletion API endpoint (DELETE /memories) that allows remote attackers to delete arbitrary user memory records by specifying user identifiers in query parameters, resulting in unauthorized data loss and denial of service. No authentication or authorization validation is performed before processing deletion requests, enabling any network-accessible attacker to target any user's data without credentials.
Technical ContextAI
mem0 is a memory management system with a REST API for storing and retrieving user-associated data. The vulnerable DELETE /memories endpoint processes requests containing user identifiers (user_id, run_id, agent_id) as query parameters without implementing CWE-306 (Missing Authentication for Critical Function) controls. The absence of authentication checks means the API layer fails to verify caller identity before authorizing destructive operations. The lack of authorization controls (access control lists or role-based restrictions) further permits any authenticated or unauthenticated caller to delete data belonging to arbitrary users.
RemediationAI
Upgrade mem0 immediately to a patched version released after 1.0.0; contact the vendor or monitor the GitHub repository (https://github.com/mem0ai/mem0) for fix availability. Until a patch is deployed, implement compensating controls: (1) Deploy mem0 behind an authentication gateway (OAuth2/JWT proxy) that validates all requests before forwarding to the API server - this adds latency but prevents unauthenticated access; (2) Apply network segmentation restricting DELETE /memories endpoint access to trusted internal clients only, blocking external requests at the firewall or load balancer - trade-off is reduced flexibility for remote integrations; (3) Disable the DELETE /memories endpoint entirely if deletion is not operationally required, removing the attack surface - verify with stakeholders that data retention policies do not depend on API-driven deletion. Monitor access logs for unusual DELETE requests to /memories as a temporary detection layer.
Same technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today