EUVD-2026-29567
GHSA-4w6c-gfx3-vghv
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/{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.
AnalysisAI
Unauthenticated deletion of arbitrary memory records in mem0 1.0.0 allows remote attackers to remove any database entry without credentials, causing unauthorized data loss and potential denial of service. The DELETE /memories/{memory_id} endpoint completely lacks authentication and authorization controls, exposing all memory records to deletion by any network-accessible attacker. No public exploit code has been identified, but the vulnerability is trivial to exploit given the straightforward API design.
Technical ContextAI
mem0 is a memory management service that exposes REST API endpoints for CRUD operations on memory records. The affected DELETE /memories/{memory_id} endpoint fails to implement authentication (CWE-862: Missing Authorization) before processing deletion requests. This allows any unauthenticated client with network access to craft HTTP DELETE requests to arbitrary memory identifiers, directly modifying or destroying persistent data in the backend database without identity verification or permission checks. The vulnerability stems from a fundamental design failure where API security was not implemented during initial development of version 1.0.0.
RemediationAI
Upgrade to a patched version of mem0 if available from the vendor (https://github.com/mem0ai/mem0); specific patch version is not provided in available data, so check the project's releases page for post-1.0.0 versions that address authentication. If immediate patching is not possible, implement network-level controls: restrict HTTP DELETE access to the /memories/{memory_id} endpoint to trusted internal networks only using firewall rules or reverse proxy (e.g., nginx, Apache) configuration, allowing requests only from authenticated application servers. Alternatively, place mem0 behind an API gateway that enforces bearer token or API key authentication before forwarding requests to the mem0 server. These workarounds add latency and require administrative overhead but prevent unauthenticated deletion attacks while patches are pending. Audit all memory records for signs of unauthorized deletion or modification and restore from backup if needed.
Authorization bypass in Mem0 self-hosted server versions through 0.2.8 allows any authenticated holder of a distributed
Unauthenticated data theft, tampering, and denial-of-service affects mem0's OpenMemory API server (openmemory/api compon
Sensitive information disclosure and server-side request forgery in mem0's self-hosted server let unauthenticated remote
mem0 1.0.0 server allows unauthenticated remote attackers to trigger memory reset and table re-creation via unprotected
Unsafe pickle deserialization in mem0 up to version 1.0.11 allows authenticated remote attackers to execute arbitrary co
mem0 1.0.0 server accepts unauthenticated POST requests to the /memories endpoint, allowing remote attackers to inject a
Same weakness CWE-862 – Missing Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today