Guides pratiques pour vous protéger — vous, votre famille et votre entreprise — contre les arnaques liées à l'IA, les deepfakes et les nouvelles menaces cyber.
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.
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.
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.
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.


