Quand votre base de données vectorielle expose une RCE pré-auth, le RAG rencontre un problème au niveau de la couche de données
Le 18 mai 2026, HiddenLayer a publié une étude sur ChromaToast — officiellement CVE-2026-45829. Score CVSS : 10,0. Vecteur d’attaque : réseau. Privilèges requis : aucun. Interaction utilisateur : aucune. La faille se situe dans le gestionnaire create_collection du serveur Python FastAPI de ChromaDB : le serveur fait confiance aux identifiants de modèles fournis par le client et agit en conséquence — y compris en chargeant du code depuis des dépôts HuggingFace externes avec trust_remote_code activé — avant même la vérification d’authentification. Un attaquant non authentifié envoie une requête HTTP, le serveur récupère et exécute le code du modèle contrôlé par l’attaquant, ce qui permet l’exécution de code arbitraire avec accès aux clés API, variables d’environnement, secrets montés et à tout fichier lisible par le processus serveur.
Le scan de HiddenLayer basé sur Shodan a révélé qu’environ 73 % des déploiements sont exposés. HiddenLayer indique avoir contacté le projet Chroma pour la première fois le 17 février 2026, avec des relances documentées les 24 février, 5 mars et 16 avril — sans aucune réponse. Le chercheur indépendant Azraelxuemo a signalé la même faille en novembre 2025 et n’a pas non plus reçu de réponse. La mesure d’atténuation provisoire consiste à restreindre le réseau. Aucun correctif n’est disponible.
5 points clés à retenir
1. ChromaToast est une faille RCE pré-auth CVSS 10.0 active dans la nature.
HiddenLayer a révélé CVE-2026-45829 le 18 mai 2026, affectant toutes les versions du serveur Python FastAPI de ChromaDB depuis la 1.0.0. Environ 73 % des déploiements accessibles sur Internet sont exploitables. Aucun correctif n’est disponible. Capital One et UnitedHealthcare figurent sur la page d’accueil de Chroma. Ce n’est pas un outil marginal — il s’agit d’une infrastructure qui exécute des RAG à grande échelle, et la réponse à l’incident commence sans solution de correction.
2. Ce bug révèle une défaillance architecturale profonde des RAG.
ChromaDB compte 13 millions de téléchargements pip mensuels et alimente les pipelines RAG de production chez Mintlify, Factory AI et Weights & Biases. Quand la base de données qui héberge les embeddings, prompts et documents récupérés est exploitable avant authentification, chaque secret lisible par le serveur est exposé — clés API, variables d’environnement, identifiants montés et tout ce qui y est connecté. Ce n’est pas une vulnérabilité de la couche applicative, mais bien de l’infrastructure de données sous-jacente.
3. L’exploitation de vulnérabilités devient le principal vecteur de compromission pour la première fois en 19 ans.
Le rapport Verizon DBIR 2026 indique que 31 % des compromissions proviennent de vulnérabilités non corrigées contre 13 % pour l’abus d’identifiants — c’est la première fois dans l’histoire du rapport que l’exploitation de failles prend la tête. IBM X-Force signale une hausse de 44 % des exploitations d’applications exposées au public d’une année sur l’autre, avec 56 % des vulnérabilités divulguées ne nécessitant aucune authentification. L’infrastructure RAG est une cible crédible dans ce contexte, et non un cas hypothétique.
4. La plupart des entreprises n’ont pas de couche de données IA gouvernée.
Seules 43 % des organisations disposent aujourd’hui d’une passerelle centralisée pour les données IA. 57 % fonctionnent avec des contrôles fragmentés, partiels ou inexistants. 90 % des organismes publics et 77 % des établissements de santé n’ont aucune centralisation. Le rythme de déploiement de l’IA dépasse la maturité de la gouvernance — et ChromaToast illustre concrètement ce décalage en production.
5. La réponse architecturale consiste à gouverner la donnée, pas à patcher l’infrastructure.
Quand les pipelines RAG accèdent aux données d’entreprise via une passerelle gouvernée avec accès zéro trust, application d’ABAC, chiffrement FIPS 140-3 et journalisation d’audit inviolable, une RCE pré-auth sur un composant ne se traduit pas par une compromission des données. La vulnérabilité devient un problème de confinement, pas d’exfiltration.
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?
Pour en savoir plus :
Pourquoi une RCE pré-auth dans une base de données vectorielle pose un problème différent
Les failles RCE pré-authentification existent. Ce qui distingue celle-ci, c’est la place de ChromaDB dans la pile IA. Une base de données vectorielle dans un pipeline RAG se trouve au même niveau que les données les plus sensibles du système : embeddings de documents d’entreprise, fragments récupérés servant de base aux réponses du modèle, prompts pouvant contenir des données réglementées, et secrets applicatifs nécessaires pour accéder aux sources de données amont. Si la base vectorielle est compromise, tout le pipeline RAG est exposé — les embeddings révèlent le contenu des documents, les prompts stockés peuvent inclure des informations personnelles identifiables, des informations médicales protégées ou des informations contrôlées, et les clés API donnent accès à tout ce qu’elles permettent d’atteindre.
La défaillance est avant tout architecturale. L’hypothèse de confiance du serveur Python de ChromaDB — à savoir qu’il est acceptable de récupérer et d’exécuter du code de modèle externe avant de vérifier l’identité du demandeur — est la même que celle qui prévaut dans la plupart des déploiements RAG actuels. La couche de récupération est considérée comme de la plomberie d’infrastructure plutôt que comme un accès gouverné aux données d’entreprise. Si la plomberie présente une RCE pré-auth, la gouvernance uniquement appliquée au-dessus, au niveau applicatif, ne peut rien compenser. L’infrastructure IA est une infrastructure de données, et les mêmes contrôles qui régissent l’accès à un dossier sensible doivent régir qui — ou quoi — peut interroger un store d’embeddings, monter un artefact de modèle ou invoquer un outil via un agent runtime.
L’exploitation de vulnérabilités est désormais le vecteur de compromission à surveiller
Le rapport Verizon DBIR 2026 montre que l’exploitation de vulnérabilités a dépassé le vol d’identifiants pour la première fois en 19 ans. Les vulnérabilités non corrigées représentent 31 % des compromissions, contre 13 % pour l’abus d’identifiants. Les organisations n’ont corrigé que 26 % des vulnérabilités connues listées par la CISA en 2025, contre 38 % en 2024. Le délai médian de correction complète est passé à 43 jours contre 32. Le rythme de remédiation des défenseurs ralentit alors que celui des attaquants s’accélère.
L’IBM X-Force 2026 Threat Intelligence Index ajoute la dimension des applications exposées au public : l’exploitation de ces applications a augmenté de 44 % en un an, l’exploitation de vulnérabilités représente 40 % des incidents observés, et 56 % des failles divulguées ne nécessitent aucune authentification. Les bases de données vectorielles sont des applications exposées dès lors qu’elles sont auto-hébergées avec un port accessible — c’est précisément ce que mesure le taux d’exposition de 73 % relevé par HiddenLayer.
Les adversaires IA vont plus vite que les correctifs
Une autre tendance, parallèle à la montée de l’exploitation des vulnérabilités, aggrave le phénomène ChromaToast. L’UK AI Security Institute rapporte que la difficulté des tâches cyber que les modèles IA de pointe peuvent accomplir doublait tous les huit mois fin 2025, puis tous les 4,7 mois en février 2026. L’AI Index 2026 de Stanford indique que le taux de résolution autonome sur le benchmark Cybench en cybersécurité est passé de 15 % en 2024 à 93 % en 2025.
La divulgation GTG-1002 d’Anthropic de novembre 2025 rend la menace concrète : un groupe parrainé par l’État chinois a utilisé Claude Code et les outils MCP pour orchestrer 80 à 90 % des tâches tactiques d’une campagne de cyber-espionnage multi-cibles sur une trentaine d’entités — reconnaissance, découverte de vulnérabilités, exploitation, mouvements latéraux, collecte d’identifiants — le tout exécuté par l’IA. Comparez avec la chronologie de ChromaDB : HiddenLayer a contacté Chroma le 17 février 2026, puis trois fois jusqu’en avril, sans réponse. La faille est publique, la logique du PoC documentée, aucun correctif n’existe. L’horloge du défenseur est à l’arrêt. Celle de l’attaquant se compte désormais en cycles de calcul.
Où en sont les entreprises sur la gouvernance des données IA
Seules 43 % des organisations disposent d’une passerelle centralisée pour les données IA. 27 % s’appuient sur des contrôles distribués avec des règles. 19 % ont des contrôles partiels ou ad hoc. 7 % n’ont aucun contrôle dédié à l’IA. Le secteur public est à 90 % sans centralisation, la santé à 77 %, les services financiers à 60 %. Ces chiffres illustrent la population exposée au scénario ChromaToast. Une organisation dotée d’une passerelle centralisée dispose d’un point unique pour appliquer authentification, autorisation, chiffrement et audit à chaque interaction avec les données IA. Une organisation avec des contrôles partiels ou absents se retrouve avec une multitude de bases vectorielles, stores d’embeddings et agents — chacun constituant une surface d’attaque pré-auth potentielle.
La réponse architecturale : gouverner la couche de données, pas le composant
L’alternative architecturale consiste à traiter l’accès aux données IA comme la sécurité d’entreprise l’a fait depuis dix ans : zéro trust à la couche données, chaque requête étant authentifiée, autorisée selon la politique, et auditée, quel que soit le composant à l’origine de la demande.
Le serveur MCP sécurisé de Kiteworks et la passerelle de données IA appliquent ce modèle. Les pipelines RAG interrogent les données d’entreprise via un pont gouverné. Les assistants IA accèdent aux fichiers via le Model Context Protocol avec authentification OAuth 2.0 — les jetons restent dans le trousseau d’OS, jamais transmis au modèle. Les règles ABAC évaluent chaque opération en temps réel. Le rate limiting empêche l’extraction massive même si un composant amont est compromis. Le chiffrement validé FIPS 140-3, la validation TLS et une appliance virtuelle durcie sécurisent toute la chaîne. Chaque interaction est journalisée en temps réel dans le SIEM via une piste d’audit inviolable.
Le test architectural est simple : si la base de données vectorielle était compromise demain, quel serait le rayon d’impact ? Dans une architecture à passerelle gouvernée, la réponse est limitée par la politique ABAC, pas par les identifiants détenus par le composant compromis. Le Réseau de données privé Kiteworks étend ce modèle à la messagerie électronique, le partage et le transfert de fichiers, MFT, SFTP, formulaires web, API et intégrations IA sous un moteur de politique unique et un journal d’audit consolidé.
Ce que les responsables sécurité doivent faire ce trimestre
Première étape : inventorier chaque base vectorielle, store d’embeddings et agent runtime accédant aux données d’entreprise. Cartographier le modèle d’authentification, l’exposition réseau et les identifiants accessibles pour chaque composant. La plupart des équipes sécurité n’ont qu’une vision partielle, car l’infrastructure IA a souvent été déployée par les équipes data science sans entrée dans le CMDB.
Deuxième étape : traiter l’infrastructure IA comme une infrastructure de production pour la gestion des vulnérabilités. Appliquer les mêmes SLA de correctifs, la même discipline de gestion de l’exposition et la même priorisation basée sur la KEV. Le constat du DBIR 2026 selon lequel seules 26 % des vulnérabilités listées KEV sont corrigées vaut autant pour les composants IA que pour l’infrastructure traditionnelle.
Troisième étape : faire transiter les accès aux données RAG et agents via une passerelle gouvernée de données IA. Seules 43 % des organisations l’ont fait. Les 57 % restantes sont confrontées au scénario ChromaToast démultiplié sur chaque workload IA. La centralisation à la couche données transforme des dizaines de surfaces d’attaque en un seul plan de contrôle gouverné.
Quatrième étape : exiger un accès zéro trust aux données pour les agents IA, comme pour les utilisateurs humains. Chaque requête IA doit être authentifiée, autorisée selon la politique, limitée en débit, chiffrée et journalisée avec attribution complète. L’AI Index 2026 de Stanford indique que les préoccupations de sécurité et de risques sont le principal frein au déploiement d’agents IA à grande échelle, citées par 62 % des organisations — l’accès zéro trust aux données est la variable maîtrisable.
Cinquième étape : instrumenter la couche de données IA pour la visibilité SIEM. Par définition, une RCE pré-auth ne génère aucun log d’authentification. La visibilité doit venir de l’amont — de la passerelle qui médie chaque interaction avec les données. Les flux SIEM en temps réel sur les accès aux données IA sont la base forensique lors de la prochaine divulgation de type ChromaToast.
Pour en savoir plus sur la protection de vos données sensibles contre les menaces liées à l’IA, réservez votre démo sans attendre !
Foire aux questions
Restreignez l’accès réseau aux seuls clients de confiance et considérez toute instance exposée comme potentiellement déjà compromise, en attendant l’enquête. Faites tourner tous les secrets lisibles par le serveur — clés API, identifiants montés, variables d’environnement. À long terme, faites transiter les accès RAG via une passerelle de données IA gouvernée ; la restriction réseau n’est qu’une mesure d’urgence, pas une architecture.
Votre exposition est réelle si un composant RAG est accessible sur Internet et non gouverné. 77 % des organisations de santé n’ont pas de passerelle centralisée pour les données IA et 14 % n’ont aucun contrôle IA dédié selon les Prévisions Kiteworks 2026. La Security Rule d’HIPAA exige des contrôles d’accès et des pistes d’audit que les composants RAG non gouvernés ne peuvent fournir. Une RCE pré-auth sur un composant hébergeant des embeddings PHI constitue un événement à déclarer.
Une RCE pré-auth dans un composant IA manipulant des informations contrôlées est un événement à reporter au titre du CMMC et du DFARS. 90 % des organismes publics n’ont pas de passerelle centralisée pour les données IA selon les Prévisions Kiteworks 2026. Les familles de contrôles AC, AU et IA du CMMC exigent une autorisation et une journalisation d’audit pour chaque accès aux données, y compris par des composants IA. La gouvernance à la couche données avec ABAC et des logs inviolables répond simultanément à ces trois exigences.
Patcher corrige une vulnérabilité sur un composant. Gouverner l’accès aux données IA détermine qui ou quoi peut accéder aux données d’entreprise, quel que soit le composant compromis en aval. Les passerelles centralisées deviennent la norme architecturale précisément parce que le rythme de découverte des vulnérabilités IA dépasse la capacité de patching — la chronologie ChromaToast (mois sans réponse, aucun correctif) l’illustre parfaitement.
Oui — c’est même la solution la plus efficiente. Un plan de contrôle gouverné remplace des dizaines de contrôles dispersés. Le serveur MCP sécurisé Kiteworks et la passerelle de données IA offrent ce point d’application unique — les petites équipes sécurité gagnent plus à centraliser qu’à patcher chaque base vectorielle, store d’embeddings et agent individuellement.
Ressources complémentaires
- Article de blog
Stratégies Zero‑Trust pour une protection abordable de la confidentialité IA - Article de blog
Pourquoi 77 % des organisations échouent sur la sécurité des données IA - eBook
AI Governance Gap : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025 - Article de blog
Il n’existe pas de « –dangerously-skip-permissions » pour vos données - Article de blog
Les régulateurs ne se contentent plus de demander si vous avez une politique IA. Ils veulent des preuves concrètes.