Les filtres de métadonnées vectorielles, un puits d'injection dans Spring AI

De quoi s’agit-il ?

Spring AI est la couche d’abstraction officielle du framework Spring pour intégrer des fonctions LLM dans des applications Java, et elle est devenue le standard de fait pour la génération augmentée par récupération (RAG) sur la JVM. Son abstraction de base vectorielle permet de stocker des embeddings puis de les interroger via un filtre de métadonnées — une petite expression du type « ne renvoyer que les documents où tenant = X et year > 2024 ». Entre avril et juin 2026, Spring a publié une série d’avis montrant que plusieurs de ces intégrations construisaient la requête sous-jacente en collant l’entrée utilisateur directement dans le langage de requête natif de la base. Le résultat est une faille d’injection classique, réapparue au cœur de la pile IA : le filtre de métadonnées, censé restreindre une recherche, devient un canal pour exécuter des requêtes arbitraires contre la base.

Deux avis résument le schéma. Le premier, publié le 27 avril 2026, est une injection SQL dans la base vectorielle Azure Cosmos DB de Spring AI, atteignable lorsqu’une application transmet des valeurs fournies par l’utilisateur comme identifiants de documents dans le chemin de suppression. Le second, publié le 12 juin 2026, concerne les bases Elasticsearch, OpenSearch et GemFire, où des caractères spéciaux dans une chaîne de filtre pouvaient forcer l’exécution de requêtes arbitraires contre ces moteurs. Les deux sont classés « High ».

Comment ça marche

L’abstraction fuit toujours au même endroit : la traduction d’un filtre de métadonnées portable en une requête concrète pour une base précise. Quand cette traduction concatène des chaînes brutes au lieu d’utiliser le mécanisme de liaison de paramètres de la base, tout caractère d’opérateur contrôlé par l’utilisateur change le sens de la requête au lieu d’être traité comme une donnée.

Dans le cas de Cosmos DB, le chemin de code affecté construisait une instruction SQL de suppression à partir d’identifiants de documents. Une application qui transmettait l’entrée d’un utilisateur final comme identifiants offrait à l’attaquant un levier pour sortir de la clause WHERE prévue et atteindre des enregistrements interdits. Pour Elasticsearch, OpenSearch et GemFire, des caractères forgés dans l’expression de filtre échappaient à la structure de requête prévue et étaient interprétés par le moteur cible. La vulnérabilité n’est pas dans la base vectorielle elle-même — Postgres/pgvector, Elasticsearch, OpenSearch, GemFire et Cosmos DB offrent tous des chemins de requête paramétrés sûrs — mais dans le code de liaison qui assemblait les requêtes par concaténation. Nous décrivons le mécanisme, pas un payload fonctionnel.

Ce point compte particulièrement pour le RAG, car les filtres de métadonnées sont généralement pilotés par le contexte de la requête : le tenant, l’utilisateur, le périmètre documentaire. C’est exactement l’entrée non fiable, propre à chaque requête, dont l’injection classique se nourrit — et les pipelines RAG l’acheminent vers une base qui contient tous les documents ingérés par l’application.

Pourquoi c’est important

Une injection dans le filtre de métadonnées fait s’effondrer l’isolation sur laquelle reposent les déploiements RAG. Si un attaquant peut réécrire le filtre, il peut potentiellement lire les documents d’autres tenants, contourner le cloisonnement des accès, ou — selon l’opération et la base — supprimer ou altérer des vecteurs stockés et leurs enregistrements source. Dans une application Java multi-tenant, c’est une atteinte directe à la confidentialité et à l’intégrité de la couche censée séparer les données des clients. La faille Cosmos DB atteint un impact élevé en confidentialité, intégrité et disponibilité ; celle d’Elasticsearch/OpenSearch/GemFire est atteignable sans authentification préalable dans les configurations affectées.

Le calendrier n’a rien d’un hasard. La presse Java autour de la conférence UberConf 2026 (14 juillet 2026) a noté que les avis de sécurité Spring avaient été multipliés par plus de dix-sept en avril 2026 par rapport à la normale, en grande partie parce que des scanners de vulnérabilités assistés par IA se sont mis à trouver des bugs dans le graphe de dépendances Spring plus vite que jamais — provoquant ce que Broadcom a décrit comme le plus gros lot de correctifs Spring de son histoire. La même couverture signale une injection distincte de langage d’expression dans du code de pipeline RAG, montée jusqu’à l’exécution de code à distance dans une preuve de concept, confirmant que la tuyauterie RAG, et pas seulement le modèle, est désormais une surface d’attaque active.

Défenses

• Mettez à jour. Passez aux versions corrigées de Spring AI — 1.0.6 / 1.1.5 pour Cosmos DB, et 1.0.9 / 1.1.8 pour Elasticsearch, OpenSearch et GemFire. Les mainteneurs indiquent qu’aucune autre mitigation n’est requise une fois le correctif appliqué.
• Ne construisez jamais les requêtes par concaténation. Utilisez l’API de requête paramétrée ou de requête préparée de chaque base afin que les valeurs influencées par l’utilisateur soient toujours liées comme des données, jamais interprétées comme de la syntaxe. C’est le correctif de fond pour toute la classe.
• Traitez le filtre de métadonnées comme une entrée non fiable. Lorsque les filtres ou les identifiants dérivent du contexte de la requête, validez-les contre une liste blanche de champs, d’opérateurs et de types de valeurs attendus avant qu’ils n’atteignent la base. Rejetez les caractères d’opérateur inattendus plutôt que de tenter de les échapper.
• Limitez les identifiants de base au moindre privilège. Le compte de la base utilisé par le service RAG doit se limiter aux collections et opérations réellement nécessaires, afin qu’une injection réussie ne puisse atteindre ni des données sans rapport ni des opérations destructrices.
• Appliquez l’isolation des tenants sous le filtre. Ne comptez pas sur une chaîne de filtre applicative comme seule frontière entre tenants ; renforcez-la avec de la sécurité au niveau des lignes, des collections par tenant ou des index séparés, pour qu’un filtre réécrit n’équivaille pas à une lecture inter-tenant.
• Journalisez et surveillez les requêtes. Capturez les requêtes générées et alertez sur les anomalies — opérateurs inattendus, filtres surdimensionnés, suppressions avec des identifiants de forme suspecte — pour détecter les tentatives d’exploitation et les régressions.

Statut

Élément	Valeur
Classe	Injection via filtres de métadonnées / identifiants dans un framework RAG
Framework affecté	Intégrations vectorielles de Spring AI 1.0.x et 1.1.x
Bases concernées	Azure Cosmos DB ; Elasticsearch, OpenSearch, GemFire (le défaut est dans le code de liaison, pas dans les bases)
Impact	Lecture inter-tenant, et selon l’opération, altération ou suppression de données
Versions corrigées	1.0.6 / 1.1.5 (Cosmos DB) ; 1.0.9 / 1.1.8 (Elasticsearch / OpenSearch / GemFire)
Divulgation	27 avril 2026 et 12 juin 2026 (avis éditeur) ; signalement responsable
Références	CVE-2026-40978, CVE-2026-47835

Dates clés : 27 avril 2026 — avis d’injection SQL sur la base vectorielle Cosmos DB (CVE-2026-40978), signalé par SharlongWen. 12 juin 2026 — avis d’injection de filtre Elasticsearch/OpenSearch/GemFire (CVE-2026-47835), signalé par Nitro Cao d’Alibaba Cloud. 14 juillet 2026 — couverture de l’écosystème Java sur la vague d’avis Spring d’avril 2026 et sur l’injection de langage d’expression dans le pipeline RAG (référencée CVE-2026-22738). Les numéros de version et crédits sont ceux indiqués dans les avis éditeur.