mem0 OpenMemory: una API sin autenticación expone memorias de agente y claves LLM

¿Qué es esto?

El 7 de julio de 2026, VulnCheck publicó dos avisos contra mem0, una de las capas de memoria de código abierto más usadas para agentes LLM (distribuida como el paquete de PyPI mem0ai). Ambas fallas residen en OpenMemory, el componente de servidor autoalojable de mem0 (openmemory/api), y comparten la misma causa raíz: endpoints HTTP críticos se registraron sin ninguna autenticación por delante.

El primer aviso cubre el acceso sin autenticación al propio almacén de memoria: un atacante que pueda alcanzar el servidor puede leer, escribir y borrar las memorias de cualquier usuario, y puede activar un interruptor de pausa global que deja el servicio fuera de servicio para todos. El segundo cubre la API de configuración, que devuelve en texto plano las claves de API de LLM almacenadas y puede abusarse para que el servidor emita solicitudes salientes elegidas por el atacante. Ambas recibieron puntuaciones CVSS del orden de 9,2 a 9,3 (crítica). Las correcciones están en el commit a3154d5 de mem0; toda versión anterior a ese commit está afectada.

Cómo funciona

mem0 dota a un agente de memoria persistente: hechos, preferencias y estado de conversación previo se escriben en un almacén y se recuperan en turnos posteriores. OpenMemory expone ese almacén mediante una API HTTP para que varios agentes e interfaces lo compartan. La clase de vulnerabilidad aquí es CWE-306, ausencia de autenticación para una función crítica: los enrutadores se montaron sin una dependencia de autenticación, de modo que los endpoints responden a cualquiera que pueda abrir una conexión hacia ellos.

Hay dos familias de endpoints afectadas. Los enrutadores de memoria aceptan un user_id proporcionado por quien llama y actúan sobre el valor recibido, sin comprobar que quien llama sea el propietario de esa identidad. Leer las memorias de otro inquilino se reduce, por tanto, a recorrer identificadores; escribirlas o borrarlas funciona igual. Un endpoint de pausa acepta una bandera global_pause=true que detiene las operaciones de memoria en todo el despliegue: una denegación de servicio en una sola solicitud.

El enrutador de configuración es peor para la higiene de secretos. Un simple GET sobre la ruta de configuración devuelve los ajustes de proveedor almacenados por el servidor, incluidas las claves de API de LLM en texto claro: la clave de OpenAI u otra que el despliegue usa para hablar con su modelo. Además, la configuración del backend de modelo local toma un valor de URL base (ollama_base_url). Como es escribible por el atacante y el servidor luego hace solicitudes hacia ella, fijarla en una dirección interna convierte al servidor en un relé de falsificación de solicitud del lado del servidor (SSRF): el aviso señala explícitamente los endpoints de metadatos de instancia en la nube como objetivo, la vía clásica hacia credenciales de nube efímeras.

El encadenamiento es el verdadero riesgo. El robo de claves en texto claro sumado a una SSRF hacia un servicio de metadatos permite a un atacante pasar de un servidor de memoria expuesto a la factura del proveedor de modelo y, potencialmente, al rol de nube bajo el que se ejecuta la instancia, sin autenticarse en ningún momento.

Por qué importa

La memoria de agente se está convirtiendo en infraestructura estándar, y autoalojar un servidor de memoria parece la opción segura y respetuosa con la privacidad. Pero una capa de memoria concentra justo los datos que quiere un atacante: todo lo que el agente ha aprendido de sus usuarios, más las credenciales que necesita para funcionar. Cuando esa capa se distribuye asumiendo que se sitúa en una red de confianza y alguien la expone —un puerto de contenedor mapeado a 0.0.0.0, un despliegue de vista previa en una IP pública, un servicio interno alcanzable mediante una SSRF en otro lugar—, el radio de impacto abarca a la vez la integridad de la memoria (envenenar lo que el agente «recuerda»), la confidencialidad (leer memorias privadas y claves) y la disponibilidad (la pausa global). El envenenamiento de memoria es, en particular, un modo de fallo silencioso: una memoria implantada puede orientar las decisiones posteriores del agente mucho después de la escritura, sin dejar rastro evidente.

Defensas

No exponga el servidor de memoria a ninguna red no confiable. Trate OpenMemory como un servicio de backend: enlácelo a localhost o a una interfaz privada, colóquelo tras un proxy inverso o pasarela con autenticación y nunca mapee su puerto a una dirección pública. Si lo ejecuta en contenedor, revise explícitamente la configuración de puertos publicados.

Actualice más allá de la corrección. El código corregido está en el commit a3154d5 de mem0 y versiones posteriores. Fije una versión corregida y considere vulnerable toda versión anterior o igual a ese commit.

Añada autenticación y autorización por inquilino en el borde. Exija un token en cada solicitud y verifique que el principal autenticado sea propietario del user_id sobre el que opera. La ausencia de autenticación y la ausencia de autorización a nivel de objeto son bugs distintos; corrija ambos, para que un token válido de un inquilino no pueda leer los datos de otro.

Saque las claves de proveedor de la configuración legible del servidor. Inyecte las claves de API de LLM desde un gestor de secretos o el entorno en tiempo de ejecución en lugar de almacenarlas donde un endpoint de configuración pueda devolverlas, limite el alcance de las claves y rote cualquier clave que haya residido en una instancia expuesta.

Bloquee la vía de SSRF. Trate toda URL base proporcionada al servidor como no confiable: use listas de permitidos para los hosts autorizados, deniegue solicitudes hacia rangos link-local, loopback y de metadatos, y exija tokens de sesión tipo IMDSv2 para que una SSRF simple no pueda leer credenciales de nube.

Vigile la firma. Alerte sobre lecturas de configuración, sobre escrituras que activen una pausa global y sobre patrones de acceso entre distintos user_id: la huella operativa de esta clase de ataque.

Status

Elemento	Referencia	Fecha	Notas
Falta de auth en la API de memoria	CVE-2026-59705	2026-07-07	Lectura/escritura/borrado sin autenticación de memorias arbitrarias; DoS vía global_pause. CWE-306
Fuga de claves + SSRF vía API de config	CVE-2026-59706	2026-07-07	Claves de API de LLM en claro vía GET de config; SSRF vía ollama_base_url. CVSS 9,3 (v3.1) / 9,2 (v4.0), CWE-306
Corrección	commit de mem0 a3154d5	2026-07	Las versiones hasta ese commit inclusive están afectadas
Reportado por	VulnCheck (CNA)	2026-07-07	Avisos y registros NVD publicados el mismo día
Marcos asociados	OWASP LLM06 (Excessive Agency) / API Security «Broken Authentication», MITRE ATLAS AML.T0024 (exfiltración)	2026	Falta de auth en un servicio de memoria de agente

Los avisos de mem0 recuerdan que las partes más nuevas de la pila de agentes —memoria, servidores de herramientas, planos de configuración— aún se distribuyen con los supuestos de confianza de red de un prototipo local. Fechas de publicación: ambos avisos y los registros NVD están fechados el 7 de julio de 2026; el commit de corrección es anterior a la divulgación.