mem0 et OpenMemory : des API sans authentification exposent mémoire et clés

De quoi s’agit-il ?

Le 7 juillet 2026, VulnCheck a publié deux avis pour mem0 et son OpenMemory API auto-hébergé — une « couche mémoire » largement déployée qui permet aux agents LLM de stocker et de relire un contexte de long terme d’une session à l’autre. Les deux failles relèvent de la même classe : absence d’authentification sur une fonction critique (CWE-306). Les routeurs d’API concernés sont livrés sans middleware d’authentification : quiconque peut atteindre le service peut l’opérer. Une faille expose le stockage mémoire ; l’autre expose l’API de configuration. Le projet a corrigé les deux dans le commit a3154d5. Les sévérités attribuées vont de 9.2 à 9.8 (critique) — accessible par le réseau, sans privilège ni interaction utilisateur.

C’est important, car un backend mémoire n’est pas un cache : c’est un contexte de confiance que l’agent relit et sur lequel il agit. Casser son intégrité ou sa confidentialité, c’est casser l’agent.

Comment ça marche

Il existe deux faiblesses indépendantes, chacune atteignable sans identifiants.

L’API mémoire enregistre ses routeurs sans garde d’authentification. Un appelant non authentifié peut fournir un user_id arbitraire et lire, écrire ou supprimer la mémoire de n’importe quel utilisateur, ou appeler un endpoint de pause avec global_pause=true pour stopper les opérations mémoire de tous les utilisateurs — un déni de service contre l’ensemble du déploiement.

L’API de configuration est pire pour le déplacement latéral. Un GET sur l’endpoint de configuration renvoie les secrets stockés — par exemple des clés OpenAI — en clair. Un PUT sur la configuration LLM permet à un attaquant de définir la valeur ollama_base_url sur une adresse interne, comme un service de métadonnées cloud, transformant le serveur en primitive de falsification de requête côté serveur (SSRF) qui atteint des ressources hors de portée directe de l’attaquant.

Réseau non fiable
      |
      v
[ API mem0 / OpenMemory ]  <- aucun middleware d'auth sur les routeurs
   |            |
   |            +-- GET  config      -> cles d'API fournisseur en clair
   |            +-- PUT  llm config  -> ollama_base_url = hote interne -> SSRF
   |
   +-- lecture/ecriture/suppression memoire (user_id arbitraire)
   +-- pause (global_pause=true)     -> deni de service

Aucun code d’exploitation n’est reproduit ici ; les endpoints ci-dessus ne sont décrits qu’au niveau déjà documenté dans l’avis public. Le point est architectural : le service mémoire supposait se trouver sur un réseau de confiance et n’imposait rien de lui-même.

Pourquoi c’est important

L’accès en écriture à la mémoire est un canal d’injection persistante. Contrairement à une injection de prompt ponctuelle, une mémoire empoisonnée est relue encore et encore, survivant d’une session à l’autre — la version durable de l’empoisonnement de mémoire d’agent. L’accès en lecture est une fuite de données pure et simple de tout ce que l’agent a choisi de mémoriser : historique de conversation, données personnelles, contexte métier. La fuite de configuration livre à un attaquant des clés d’API LLM actives (abus de facturation et accès au modèle), et le chemin SSRF peut s’escalader en vol d’identifiants cloud via les endpoints de métadonnées.

La surface d’exposition est vaste car ces services sont souvent liés à 0.0.0.0 ou déposés sur un réseau interne en supposant qu’« interne » signifie « de confiance ». Les scans à l’échelle d’Internet montrent régulièrement que cette hypothèse est fausse — des centaines de milliers de services IA sont exposés. C’est le même schéma de faille backend, pas modèle que l’on retrouve dans toute la pile d’outillage des agents : la vraie faille est dans la plomberie, pas dans le prompt.

Défenses

Mettez d’abord à jour mem0 au-delà du commit de correction ; le patch ajoute l’authentification manquante. Au-delà du patch, traitez la couche mémoire comme un vrai service avec une vraie frontière de confiance.

N’exposez pas les API mémoire ou configuration à des réseaux non fiables — liez-les à localhost ou placez-les derrière une passerelle authentifiée, et isolez-les de l’Internet ouvert. Imposez l’authentification et l’autorisation dans le service lui-même, et dérivez le user_id du principal authentifié côté serveur plutôt que de faire confiance à une valeur fournie par le client, afin qu’un locataire ne puisse pas adresser la mémoire d’un autre. Gardez les identifiants fournisseur hors d’un stockage de configuration en clair : utilisez un gestionnaire de secrets et restreignez les endpoints de configuration aux administrateurs. Ajoutez des contrôles anti-SSRF sur toute URL acceptée par la configuration — liste blanche d’hôtes autorisés, blocage des plages link-local et métadonnées comme 169.254.169.254, et désactivation d’IMDSv1. Enfin, appliquez la défense en profondeur sur le chemin de lecture : traitez les mémoires relues comme des entrées non fiables, en suivant leur provenance pour qu’une entrée empoisonnée ne puisse pas piloter silencieusement un appel d’outil — la même intuition que derrière le cadre du triptyque létal : données privées, contenu non fiable et voie d’exfiltration.

Statut

Élément	Référence	Date	Notes
Accès mémoire non authentifié (lecture/écriture/suppression, DoS)	CVE-2026-59705 (VulnCheck)	2026-07-07	CVSS 9.8 critique ; user_id arbitraire, DoS global_pause
Exposition de clés en clair + SSRF via l’API config	CVE-2026-59706 (VulnCheck)	2026-07-07	CVSS 9.3 / 9.2 ; SSRF ollama_base_url, CWE-306
Correctif	commit mem0 a3154d5	2026-07	Ajoute l’authentification aux routeurs concernés

La leçon est ancienne et se répète à l’ère des agents : une couche mémoire est une frontière de sécurité, pas un détail d’implémentation. Si elle n’authentifie rien, un attaquant peut réécrire ce que votre agent croit, lire ce qu’il sait et voler les clés qui le font tourner — le tout avant même le premier prompt.