Une faille ChromaDB non corrigée laisse les serveurs ouverts à l’exécution de code à distance

Les chercheurs ont publié des détails sur une vulnérabilité critique dans ChromaDB qui pourrait permettre à des attaquants non authentifiés d’exécuter du code arbitraire et d’accéder à des données sensibles sur les machines exécutant la base de données vectorielles open source.

Le problème, identifié comme CVE-2026-45829, se trouve sur le serveur API de ChromaDB et a été publié par des chercheurs de HiddenLayer après avoir apparemment échoué à entrer en contact avec les développeurs de ChromaDB, l’une des bases de données vectorielles les plus populaires utilisées pour les applications d’IA.

La vulnérabilité provient d’une condition de concurrence entre le code utilisé par ChromaDB pour analyser les références du modèle d’intégration et le code qu’il utilise pour effectuer une vérification d’authentification. Les attaquants peuvent exploiter cette faille en envoyant des requêtes pour charger des configurations de modèles malveillants hébergés sur Hugging Face.

« L’authentification ne manque pas, elle est simplement au mauvais endroit », ont déclaré les chercheurs de la société de sécurité HiddenLayer dans leur rapport. « Au moment où il se déclenche, le modèle a déjà été récupéré et exécuté. Le serveur rejette la demande, renvoie un 500 et la charge utile de l’attaquant est déjà exécutée. »

Selon HiddenLayer, la faille existe dans ChromaDB depuis la version 1.0.0 jusqu’à la version 1.5.8, et plusieurs tentatives de la signaler aux développeurs depuis février en utilisant différents canaux de communication sont restées sans réponse, ce qui a conduit à une divulgation publique. Plus de 73 % des instances ChromaDB accessibles publiquement sur Internet et trouvables via le moteur de recherche Shodan exécutent une version vulnérable.

En attendant qu’un correctif soit disponible, les chercheurs conseillent de déployer des serveurs ChromaDB en utilisant l’implémentation Rust, qui n’est pas affectée, au lieu du serveur Python FastAPI. L’accès réseau au port ChromaDB doit également être limité aux adresses IP de confiance uniquement.

Deux problèmes distincts se combinent dans un RCE non authentifié

Les bases de données vectorielles telles que ChromaDB sont souvent utilisées pour améliorer les connaissances des LLM avec des données tierces ou spécifiques à l’entreprise dans le cadre de flux de travail de génération augmentée par récupération (RAG). Ces données, généralement d’origine non structurée, sont stockées dans une base de données vectorielles sous forme de représentations mathématiques appelées intégrations vectorielles.

Pour convertir des données non structurées telles que du texte, des images ou de l’audio en intégrations vectorielles, des algorithmes d’apprentissage automatique spécialisés appelés modèles d’intégration doivent être utilisés. Ces modèles peuvent être spécialisés pour des cas d’utilisation spécifiques. En conséquence, ChromaDB et d’autres bases de données vectorielles offrent aux utilisateurs la possibilité de choisir entre différents modèles d’intégration pour ces conversions.

ChromaDB classe les documents dans des collections, et chaque collection peut se voir attribuer une fonction d’intégration spécifique qui dicte la manière dont les documents sont intégrés, avec quel modèle et avec quels paramètres. L’un de ces paramètres peut être trust_remote_code: truequi indique au chargeur de modèle de télécharger et d’exécuter tous les fichiers de module Python supplémentaires livrés avec le modèle.

En conséquence, des attaquants non authentifiés peuvent envoyer une requête au serveur API ChromaDB pour configurer une nouvelle collection avec une fonction d’intégration personnalisée qui pointe vers un modèle malveillant qu’ils ont publié sur Hugging Face, ont découvert les chercheurs de HiddenLayer.

« Il s’agit de la même classe de risque que celle sur laquelle nous avons déjà parlé dans le contexte de modèles malveillants sur Hugging Face et de désérialisation dangereuse dans les artefacts ML », ont déclaré les chercheurs de HiddenLayer. « Un modèle n’est pas une donnée passive. C’est du code, et en charger un à partir d’une source non fiable équivaut à exécuter du code non fiable. »

Mais l’authentification des points de terminaison de l’API de ChromaDB ne devrait-elle pas empêcher que cela se produise ?

C’est là qu’intervient le deuxième problème. Il s’avère que le code du serveur ChromaDB traite ces requêtes avant de vérifier l’authentification. Et pendant le traitement de la demande, il récupère la référence du modèle depuis Hugging Face pour configurer la configuration des intégrations.

Ainsi, même si la collection n’est finalement pas créée en raison de l’échec de la vérification d’authentification, le code Python malveillant accompagnant le modèle est toujours téléchargé et exécuté.

« De l’extérieur, cela semble être un échec d’appel API », ont déclaré les chercheurs. « (Mais) du côté de l’attaquant, il y a un shell sur le serveur. »

Étant donné que le code de l’attaquant hérite des autorisations de l’utilisateur exécutant le serveur API ChromaDB, il a accès à tout ce qui se trouve sur la machine à laquelle le processus serveur a également accès. Cela signifie les variables d’environnement, les clés API, les secrets montés et les données stockées sur le disque.

Il s’agit de la dernière d’une série d’attaques rendues possibles grâce à des modèles d’IA conçus de manière malveillante et à leurs fichiers de configuration correspondants. Plus tôt ce mois-ci, les chercheurs de HiddenLayer ont montré comment l’exécution de code à distance peut être réalisée en apportant des modifications mineures au fichier tokenizer.json d’un modèle, qui est utilisé pour mapper les ID de jeton à des mots ou des caractères créant un alphabet que le modèle utilise pour générer ses sorties.

L’année dernière, des chercheurs ont montré comment des attaquants pouvaient cacher du code malveillant dans des fichiers Python Pickle, un format couramment utilisé pour distribuer des modèles d’IA.