mem0 OpenMemory : une API sans authentification expose mémoires d'agent et clés LLM

De quoi s’agit-il ?

Le 7 juillet 2026, VulnCheck a publié deux avis visant mem0, l’une des couches de mémoire open source les plus utilisées pour les agents LLM (distribuée via le paquet PyPI mem0ai). Les deux failles se situent dans OpenMemory, le composant serveur auto-hébergeable de mem0 (openmemory/api), et partagent la même cause racine : des endpoints HTTP critiques ont été exposés sans aucune authentification en amont.

Le premier avis concerne l’accès non authentifié au magasin de mémoire lui-même : un attaquant capable d’atteindre le serveur peut lire, écrire et supprimer les mémoires de n’importe quel utilisateur, et peut déclencher un interrupteur de pause globale qui met le service hors service pour tout le monde. Le second concerne l’API de configuration, qui renvoie les clés d’API LLM stockées en clair et peut être détournée pour faire émettre au serveur des requêtes sortantes choisies par l’attaquant. Les deux failles ont reçu des scores CVSS de l’ordre de 9,2 à 9,3 (critique). Les correctifs figurent dans le commit a3154d5 de mem0 ; toute version antérieure à ce commit est affectée.

Comment ça marche

mem0 dote un agent d’une mémoire persistante : faits, préférences et état de conversation antérieur sont écrits dans un magasin puis récupérés aux tours suivants. OpenMemory expose ce magasin via une API HTTP afin que plusieurs agents et interfaces le partagent. La classe de vulnérabilité ici est CWE-306, absence d’authentification pour une fonction critique : les routeurs ont été montés sans dépendance d’authentification, si bien que les endpoints répondent à quiconque peut ouvrir une connexion vers eux.

Deux familles d’endpoints sont concernées. Les routeurs de mémoire acceptent un user_id fourni par l’appelant et agissent sur la valeur transmise, sans vérifier que l’appelant possède bien cette identité. Lire les mémoires d’un autre locataire revient donc à parcourir les identifiants ; les écrire ou les supprimer fonctionne de la même façon. Un endpoint de pause accepte un drapeau global_pause=true qui suspend les opérations de mémoire sur tout le déploiement — un déni de service en une seule requête.

Le routeur de configuration est pire pour l’hygiène des secrets. Un simple GET sur le chemin de configuration renvoie les paramètres de fournisseur stockés par le serveur, y compris les clés d’API LLM en clair — la clé OpenAI ou autre que le déploiement utilise pour dialoguer avec son modèle. Par ailleurs, la configuration du backend de modèle local prend une valeur d’URL de base (ollama_base_url). Comme elle est modifiable par l’attaquant et que le serveur émet ensuite des requêtes vers elle, la définir sur une adresse interne transforme le serveur en relais de falsification de requête côté serveur (SSRF) — l’avis cite explicitement les endpoints de métadonnées d’instance cloud comme cible, le chemin classique vers des identifiants cloud éphémères.

L’enchaînement est le vrai risque. Le vol de clés en clair combiné à une SSRF vers un service de métadonnées permet à un attaquant de passer d’un serveur de mémoire exposé à la facture du fournisseur de modèle et, potentiellement, au rôle cloud sous lequel tourne l’instance — sans jamais s’authentifier.

Pourquoi c’est important

La mémoire d’agent devient une infrastructure standard, et auto-héberger un serveur de mémoire semble être le choix sûr, respectueux de la vie privée. Mais une couche de mémoire concentre exactement les données que veut un attaquant : tout ce que l’agent a appris de ses utilisateurs, plus les identifiants dont il a besoin pour fonctionner. Quand cette couche est livrée en supposant qu’elle se trouve sur un réseau de confiance et que quelqu’un l’expose — un port de conteneur mappé sur 0.0.0.0, un déploiement de préinstallation sur une IP publique, un service interne atteignable via une SSRF ailleurs — le rayon d’impact couvre à la fois l’intégrité de la mémoire (empoisonner ce dont l’agent « se souvient »), la confidentialité (lire les mémoires privées et les clés) et la disponibilité (la pause globale). L’empoisonnement de mémoire est en particulier un mode de défaillance discret : une mémoire implantée peut orienter les décisions ultérieures de l’agent longtemps après l’écriture, sans laisser de trace évidente.

Défenses

N’exposez pas le serveur de mémoire à un réseau non fiable. Traitez OpenMemory comme un service backend : liez-le à localhost ou à une interface privée, placez-le derrière un reverse proxy ou une passerelle authentifiante, et ne mappez jamais son port sur une adresse publique. En conteneur, vérifiez explicitement la configuration des ports publiés.

Mettez à jour au-delà du correctif. Le code corrigé se trouve dans le commit a3154d5 de mem0 et les versions ultérieures. Épinglez une version corrigée et considérez toute version antérieure ou égale à ce commit comme vulnérable.

Ajoutez authentification et autorisation par locataire à la périphérie. Exigez un jeton sur chaque requête et vérifiez que le principal authentifié possède bien le user_id sur lequel il agit. L’absence d’authentification et l’absence d’autorisation au niveau des objets sont deux bugs distincts ; corrigez les deux, afin qu’un jeton valide pour un locataire ne puisse pas lire les données d’un autre.

Sortez les clés de fournisseur de la configuration lisible du serveur. Injectez les clés d’API LLM depuis un gestionnaire de secrets ou l’environnement à l’exécution plutôt que de les stocker là où un endpoint de configuration peut les renvoyer, restreignez la portée des clés et faites tourner toute clé ayant résidé sur une instance exposée.

Bloquez le chemin de SSRF. Traitez toute URL de base fournie au serveur comme non fiable : mettez en liste d’autorisation les hôtes permis, refusez les requêtes vers les plages link-local, loopback et de métadonnées, et exigez des jetons de session de type IMDSv2 pour qu’une simple SSRF ne puisse pas lire les identifiants cloud.

Surveillez la signature. Alertez sur les lectures de configuration, sur les écritures qui basculent une pause globale et sur les schémas d’accès inter-user_id — l’empreinte opérationnelle de cette classe d’attaque.

Status

Élément	Référence	Date	Notes
Absence d’auth sur l’API de mémoire	CVE-2026-59705	2026-07-07	Lecture/écriture/suppression non authentifiées de mémoires arbitraires ; DoS via global_pause. CWE-306
Fuite de clés + SSRF via l’API de config	CVE-2026-59706	2026-07-07	Clés d’API LLM en clair via GET de config ; SSRF via ollama_base_url. CVSS 9,3 (v3.1) / 9,2 (v4.0), CWE-306
Correctif	commit mem0 a3154d5	2026-07	Les versions jusqu’à ce commit inclus sont affectées
Signalé par	VulnCheck (CNA)	2026-07-07	Avis et fiches NVD publiés le même jour
Cadres associés	OWASP LLM06 (Excessive Agency) / API Security « Broken Authentication », MITRE ATLAS AML.T0024 (exfiltration)	2026	Absence d’auth sur un service de mémoire d’agent

Les avis mem0 rappellent que les parties les plus récentes de la pile d’agents — mémoire, serveurs d’outils, plans de configuration — sont encore livrées avec les hypothèses de confiance réseau d’un prototype local. Dates de publication : les deux avis et les fiches NVD sont datés du 7 juillet 2026 ; le commit de correctif précède la divulgation.