Le endpoint de configuration de Cognee laissait n'importe quel compte repointer le fournisseur LLM de toute l'instance

En bref Une vulnérabilité divulguée le 7 juillet 2026 dans Cognee — une plateforme open source populaire de « mémoire IA » pour agents — révèle un endpoint de réglages qui modifiait la configuration du fournisseur LLM à l’échelle de toute l’instance sans aucun contrôle admin ou superuser. N’importe quel compte auto-enregistré pouvait faire pointer tous les appels de modèle du serveur vers un endpoint qu’il contrôlait, transformant le moteur de mémoire en canal d’exfiltration pour tous les utilisateurs. Les versions antérieures à 1.2.0 sont concernées ; le correctif est dans la 1.2.0. Il s’agit d’une analyse d’autorisation défaillante, pas d’un exploit.

De quoi s’agit-il ?

Cognee est une couche de mémoire open source pour agents LLM : on .add() des documents, on les .cognify() en un graphe de connaissances avec embeddings, puis on .search() sur le résultat. Elle combine un graphe, un magasin de vecteurs et des métadonnées relationnelles en un service unique de « mémoire persistante ». Sous licence Apache-2.0, elle compte largement plus de dix mille étoiles GitHub et se déploie aussi bien en auto-hébergement qu’en environnement multi-utilisateurs.

La faille, publiée dans l’écosystème CVE le 7 juillet 2026 et documentée par un avis VulnCheck et le suivi d’incidents de Cognee, est un contrôle d’autorisation manquant sur l’API de réglages. La route qui écrit la configuration du fournisseur LLM du serveur n’effectuait aucune vérification admin ou superuser : n’importe quel compte — y compris un compte créé par l’attaquant via l’auto-enregistrement ouvert — pouvait l’écraser. La faille est notée CVSS 9.1 (critique), avec un fort impact sur la confidentialité et l’intégrité, et classée comme absence d’authentification pour une fonction critique.

Comment ça marche

Il n’y a pas de payload exotique ici. Le problème est qui a le droit d’appeler une fonction privilégiée, et la réponse était « tout le monde ». La séquence ressemble à ceci :

Détournement du fournisseur à l'échelle de l'instance (versions vulnérables)
---------------------------------------------------------------------------
1. L'attaquant s'auto-enregistre un compte normal sur l'instance Cognee
2. L'attaquant appelle le endpoint de réglages pour écrire la config du fournisseur LLM
   --> aucun contrôle admin / superuser n'est effectué
3. La config pointe l'URL de base / le fournisseur vers un endpoint contrôlé par l'attaquant
4. Un singleton à l'échelle du processus met en cache cette config pour tout le serveur
5. Les .cognify() et .search() de chaque utilisateur routent désormais prompts + documents
   via le endpoint de l'attaquant

L’amplificateur critique est l’étape 4. Comme la configuration vit dans un cache singleton à l’échelle du processus, une seule écriture n’affecte pas que la session de l’attaquant — elle change le fournisseur pour toute l’instance. À partir de là, prompts, documents téléversés, entités extraites et contenu du graphe de connaissances de chaque utilisateur transitent par une infrastructure contrôlée par l’attaquant. Une atteinte à la confidentialité (lire les données de tous) et à l’intégrité (réinjecter des sorties de modèle manipulées dans la mémoire partagée) surviennent simultanément, sans privilège ni interaction utilisateur.

Pourquoi c’est important

Les plateformes de « mémoire » d’agents deviennent une infrastructure partagée de confiance : les équipes y déversent documents internes, historiques de conversation et entités extraites précisément pour que plusieurs agents et utilisateurs interrogent un cerveau commun. Cela fait de la configuration du fournisseur un réglage bijou de la couronne — il décide où est envoyé chaque prompt et chaque document. Traiter « changer l’endpoint du modèle » comme une action utilisateur ordinaire, plutôt que comme une action administrative privilégiée, fait s’effondrer entièrement la frontière entre tenants.

La leçon plus large ne concerne pas un seul projet. À mesure que l’outillage LLM ajoute à la hâte pages de réglages, panneaux d’administration et inscription en libre-service, l’échec classique des applications web — un endpoint modifiant l’état sans jamais vérifier le rôle de l’appelant — réapparaît avec un rayon d’impact plus lourd, car un seul champ inscriptible contrôle désormais le routage de tout le trafic IA de la machine. Un singleton global que tout appelant authentifié peut réécrire, c’est du contrôle d’accès défaillant (CWE-306 / autorisation manquante au niveau fonction), le bug même dont l’OWASP Top 10 avertit depuis des années, déguisé en IA.

Défenses

1. Passez à Cognee 1.2.0 ou plus récent. Le correctif ajoute le contrôle d’autorisation sur le chemin des réglages ; en auto-hébergement, patchez d’abord et vérifiez dans les notes de version toute configuration à repositionner.
2. Verrouillez l’inscription et l’exposition réseau. Ne laissez pas l’auto-enregistrement ouvert sur une instance de mémoire accessible depuis Internet. Placez-la derrière une entrée authentifiée et restreignez qui peut atteindre l’API.
3. Imposez une autorisation au niveau fonction sur chaque route modifiant l’état. Tout endpoint qui écrit une configuration globale ou de fournisseur doit vérifier un rôle admin/superuser côté serveur — ne comptez jamais sur l’interface pour masquer le bouton. Auditez votre propre outillage IA à la recherche de routes de réglages qui l’omettent.
4. Traitez la config fournisseur/URL de base comme un secret privilégié. Fixez les endpoints fournisseurs autorisés via l’environnement ou la config de déploiement plutôt que par un champ inscriptible à l’exécution, et alertez sur tout changement de l’URL de base du modèle.
5. Surveillez l’egress du service de mémoire. Des appels de modèle partant soudainement vers un hôte inattendu sont un indicateur à fort signal ; surveillez et mettez en liste blanche les destinations sortantes des composants d’inférence et de mémoire.

Status

Élément	Référence	Date	Notes
Avis	VulnCheck — CVE-2026-58473	2026-07-07	Écrasement non autorisé de la config LLM via l’API de réglages
Classe de faiblesse	CWE-306	—	Authentification / autorisation manquante pour une fonction critique
Sévérité	CVSS 3.1 base 9.1 (critique)	—	AV:N/AC:L/PR:N/UI:N — fort impact confidentialité & intégrité
Versions affectées	Cognee	< 1.2.0	Déploiements multi-utilisateurs / auto-hébergés avec auto-enregistrement
Version corrigée	Cognee 1.2.0	2026-07	Contrôle admin ajouté sur le chemin des réglages (commit d10b1b7)

Le cadrage honnête n’est pas « une mémoire IA s’est fait pirater ». C’est qu’un service de mémoire partagée route les données de tous par un endpoint configurable unique, et que la plus vieille règle du contrôle d’accès s’applique toujours : une fonction qui change le comportement de tout le serveur doit vérifier que l’appelant a le droit de le changer.