mem0 y OpenMemory: APIs sin autenticación exponen memoria y claves

¿Qué es esto?

El 7 de julio de 2026, VulnCheck publicó dos avisos para mem0 y su OpenMemory API autoalojada — una «capa de memoria» ampliamente desplegada que permite a los agentes LLM almacenar y recuperar contexto de largo plazo entre sesiones. Ambos fallos son de la misma clase: falta de autenticación en una función crítica (CWE-306). Los routers de API afectados se distribuyen sin middleware de autenticación, de modo que cualquiera que pueda alcanzar el servicio puede operarlo. Un fallo expone el almacén de memoria; el otro expone la API de configuración. El proyecto corrigió ambos en el commit a3154d5. Las severidades asignadas van de 9.2 a 9.8 (crítico) — accesible por red, sin privilegios ni interacción del usuario.

Esto importa porque un backend de memoria no es una caché: es contexto de confianza que el agente relee y sobre el que actúa. Romper su integridad o su confidencialidad rompe al agente.

Cómo funciona

Existen dos debilidades independientes, cada una alcanzable sin credenciales.

La API de memoria registra sus routers sin ninguna protección de autenticación. Un llamante no autenticado puede aportar un user_id arbitrario y leer, escribir o borrar la memoria de cualquier usuario, o invocar un endpoint de pausa con global_pause=true para detener las operaciones de memoria de todos los usuarios — una denegación de servicio contra todo el despliegue.

La API de configuración es peor para el movimiento lateral. Un GET sobre el endpoint de configuración devuelve los secretos almacenados — por ejemplo claves de OpenAI — en texto plano. Un PUT sobre la configuración del LLM permite a un atacante fijar el valor ollama_base_url en una dirección interna, como un servicio de metadatos en la nube, convirtiendo el servidor en una primitiva de falsificación de petición del lado del servidor (SSRF) que alcanza recursos fuera del alcance directo del atacante.

Red no confiable
      |
      v
[ API mem0 / OpenMemory ]  <- sin middleware de auth en los routers
   |            |
   |            +-- GET  config      -> claves de API del proveedor en claro
   |            +-- PUT  llm config  -> ollama_base_url = host interno -> SSRF
   |
   +-- lectura/escritura/borrado de memoria (user_id arbitrario)
   +-- pause (global_pause=true)     -> denegacion de servicio

Aquí no se reproduce ningún código de explotación; los endpoints anteriores solo se describen al nivel ya documentado en el aviso público. El punto es arquitectónico: el servicio de memoria daba por hecho que estaba en una red de confianza y no imponía nada por sí mismo.

Por qué importa

El acceso de escritura a la memoria es un canal de inyección persistente. A diferencia de una inyección de prompt puntual, una memoria envenenada se relee una y otra vez, sobreviviendo entre sesiones — la versión duradera del envenenamiento de memoria de agentes. El acceso de lectura es una fuga de datos pura de todo lo que el agente decidió recordar: historial de conversación, datos personales y contexto de negocio. La fuga de configuración entrega al atacante claves de API de LLM activas (abuso de facturación y acceso al modelo), y la vía SSRF puede escalar hasta el robo de credenciales de la nube mediante los endpoints de metadatos.

La superficie de exposición es amplia porque estos servicios suelen enlazarse a 0.0.0.0 o colocarse en una red interna asumiendo que «interno» significa «de confianza». Los escaneos a escala de Internet muestran una y otra vez que esa suposición es falsa — cientos de miles de servicios de IA están expuestos. Es el mismo patrón de fallo backend, no modelo que se ve en toda la pila de herramientas de agentes: la brecha interesante está en la fontanería, no en el prompt.

Defensas

Actualice primero mem0 más allá del commit de corrección; el parche añade la autenticación que faltaba. Más allá del parche, trate la capa de memoria como un servicio real con una frontera de confianza real.

No exponga las API de memoria o de configuración a redes no confiables — enlácelas a localhost o colóquelas tras una pasarela autenticada, y segmentelas lejos de la Internet abierta. Imponga autenticación y autorización en el propio servicio, y derive el user_id del principal autenticado en el lado del servidor en lugar de confiar en un valor aportado por el cliente, para que un inquilino no pueda direccionar la memoria de otro. Mantenga las credenciales del proveedor fuera de un almacén de configuración en texto plano: use un gestor de secretos y restrinja los endpoints de configuración a los administradores. Añada controles anti-SSRF sobre cualquier URL que acepte la configuración — lista de permitidos de hosts, bloqueo de rangos link-local y de metadatos como 169.254.169.254, y desactivación de IMDSv1. Por último, aplique defensa en profundidad en la vía de lectura: trate las memorias recuperadas como entrada no confiable, siguiendo su procedencia para que una entrada envenenada no pueda dirigir en silencio una llamada a herramienta — la misma intuición que hay tras el marco de la tríada letal: datos privados, contenido no confiable y una vía de exfiltración.

Estado

Elemento	Referencia	Fecha	Notas
Acceso a memoria sin autenticar (lectura/escritura/borrado, DoS)	CVE-2026-59705 (VulnCheck)	2026-07-07	CVSS 9.8 crítico; user_id arbitrario, DoS global_pause
Exposición de claves en claro + SSRF vía API de config	CVE-2026-59706 (VulnCheck)	2026-07-07	CVSS 9.3 / 9.2; SSRF ollama_base_url, CWE-306
Corrección	commit mem0 a3154d5	2026-07	Añade autenticación a los routers afectados

La lección es vieja y se repite en la era de los agentes: una capa de memoria es una frontera de seguridad, no un detalle de implementación. Si no autentica nada, un atacante puede reescribir lo que su agente cree, leer lo que sabe y robar las claves con las que funciona — todo antes de intercambiar un solo prompt.