Une seule requête HTTP donne un shell sur la majorité des serveurs ChromaDB exposés

Une RCE pré-auth dans l'une des bases vectorielles les plus déployées vient de devenir publique — et l'éditeur n'a jamais répondu

Le 18 mai 2026, HiddenLayer a divulgué CVE-2026-45829, une vulnérabilité de sévérité maximale dans le serveur Python FastAPI de ChromaDB. La faille, surnommée « ChromaToast », permet à n'importe quel attaquant non authentifié ayant un accès réseau de déclencher l'exécution de code arbitraire en envoyant une seule requête HTTP forgée. HiddenLayer a d'abord signalé le problème à ChromaDB le 17 février 2026. Trois mois et quatre relances plus tard, il n'existe toujours pas de version corrigée.

BleepingComputer et SecurityWeek ont tous deux confirmé la divulgation le 19 mai. Le scan Shodan qui accompagne la recherche montre que 73 % des instances ChromaDB exposées sur Internet tournent dans une version affectée.

Ce que l'on sait

ChromaDB est la base vectorielle qui sous-tend une large part de la stack RAG en production — 13 millions de téléchargements pip par mois, des déploiements publics en production chez Mintlify, Weights & Biases et Factory AI, et une page d'accueil qui liste Capital One et UnitedHealthcare parmi ses clients. La CVE touche les versions 1.0.0 à 1.5.8 du serveur Python. Le frontend Rust n'est pas affecté. Le writeup technique complet est disponible auprès de l'équipe de recherche HiddenLayer.

• L'endpoint vulnérable est la route de création de collection. Le serveur accepte une configuration de fonction d'embedding fournie par le client, va chercher le modèle nommé sur HuggingFace, et l'instancie — tout cela avant la moindre vérification d'authentification.
• Le client contrôle deux entrées qui comptent : model_name (qui peut pointer vers n'importe quel dépôt HuggingFace) et le flag trust_remote_code: true (qui dit à HuggingFace de télécharger et d'exécuter le code Python embarqué dans le modèle).
• Une fois le modèle exécuté, le serveur déclenche son contrôle d'auth, renvoie un 500, et donne l'illusion d'un appel API raté vu de l'extérieur. L'attaquant a déjà un shell avec accès aux variables d'environnement, aux secrets montés et aux données sur disque.
• La timeline de divulgation de HiddenLayer montre que le report a été envoyé à l'adresse indiquée sur la page sécurité de ChromaDB, puis relancé quatre fois — y compris via IT-ISAC. Aucun de ces messages n'a reçu de réponse.

Pourquoi c'est important

Les bases vectorielles sont en aval de chaque pipeline d'embedding et en amont de chaque agent RAG. Un shell sur le process ChromaDB donne à l'attaquant les variables d'environnement, les secrets montés, les fichiers de modèles et les documents embarqués que l'application avait confiés à ce process. Pour la plupart des déploiements en production, ça veut dire les clés d'API du fournisseur de LLM, les credentials de stockage cloud dont l'indexeur avait besoin, et les documents source en cours d'embedding — souvent de la donnée client.

Le problème de fond n'est pas spécifique à ChromaDB. Tout service IA qui charge des modèles depuis un registre public hérite des hypothèses de confiance de ce registre. Un modèle n'est pas de la donnée passive ; c'est du code, et trust_remote_code: true est le flag qui dit « j'ai lu ce code et j'accepte ce qu'il fait ». Laisser un utilisateur non authentifié positionner ce flag à la place du serveur n'est pas un bug de parsing — c'est un bug d'architecture.

Ce qu'il faut faire

1. Sortir le serveur Python FastAPI de l'Internet public aujourd'hui. Si vous ne pouvez pas migrer vers le chemin de déploiement Rust, mettez le port de l'API derrière un réseau privé ou un proxy zero-trust. La fonctionnalité vulnérable existe dans toutes les versions depuis la 1.0.0 — il n'y a pas de version corrigée vers laquelle mettre à jour.
2. Considérer toute instance exposée à Internet comme potentiellement compromise. Faites tourner les clés du fournisseur de LLM, les credentials cloud et tout autre secret qui a vécu dans l'environnement du process, et revoyez le stockage des données embarquées par l'application depuis la 1.0.0.
3. Scanner les artefacts de modèles avant qu'ils n'atteignent un runtime. Les charges trust_remote_code malveillantes ont des motifs identifiables dans les fichiers de module qu'elles livrent. Appliquez aux pulls HuggingFace la même discipline de provenance que celle déjà appliquée à npm et PyPI.

À retenir

Le motif qui a cassé ChromaDB — faire confiance à un identifiant de modèle fourni par le client puis n'authentifier qu'après — va réapparaître dans d'autres projets d'infrastructure IA, parce que la facilité du « tu pulles juste le modèle depuis HuggingFace » pousse chaque framework dans ce sens. CVE-2026-45829 est une faille de sévérité maximale dans un produit largement déployé aujourd'hui. Ce qui compte pour demain, c'est la leçon d'architecture : une configuration de fonction d'embedding soumise par un utilisateur non fiable est une exécution de code contrôlée par l'attaquant. Construisez le périmètre en conséquence.