En bref

  • VMware publie le 9 mai 2026 trois vulnérabilités HIGH affectant Spring AI 1.0.x et 1.1.x.
  • CVE-2026-41705 (CVSS 8.6) : injection de filtre dans MilvusVectorStore. CVE-2026-41712 et 41713 : fuites entre conversations et empoisonnement de mémoire.
  • Patches : Spring AI 1.0.7 ou 1.1.6. Tous les déploiements RAG ou chat avec mémoire persistante sont concernés.

Les faits

VMware a publié le 9 mai 2026 un bulletin de sécurité Spring AI couvrant trois vulnérabilités classées HIGH qui visent le cœur des architectures RAG et chat persistant construites sur Spring AI, le framework Java officiel de l''écosystème Spring pour l''intégration des modèles de langage. Les trois failles touchent à la fois la branche stable 1.0.x et la branche en pré-2.0 1.1.x, ce qui signifie qu''aucune version actuelle de Spring AI n''est à jour par défaut. Le bulletin a été immédiatement relayé par TheHackerWire, CVEFeed et SOC Prime, qui notent un timing particulier : Spring AI 2.0 est annoncé pour le 28 mai 2026 et la pression de migration s''accumule sur les équipes Java IA.

La plus sévère des trois est CVE-2026-41705, score CVSS 8.6, qui frappe l''implémentation MilvusVectorStore#doDelete(List) du module Spring AI Vector Stores. Le code de suppression construit la filter expression Milvus en concaténant directement les identifiants de documents fournis sans assainissement. Un attaquant capable de soumettre des document IDs contrôlés — typiquement via une API métier exposant la suppression de documents indexés — peut injecter des expressions Milvus arbitraires et déclencher des opérations massives non autorisées sur la base vectorielle : suppression silencieuse de tous les documents d''un namespace, exfiltration partielle via des filtres bool de retour, ou empoisonnement par modification d''index si des opérations chaînées sont exposées. La vulnérabilité est qualifiée d''injection by design parce que la filter expression Milvus est un mini-langage interprété côté serveur de la base vectorielle.

Les deux autres CVE, 41712 et 41713, ciblent le composant Chat Memory de Spring AI, brique standard pour persister l''historique conversationnel d''un utilisateur entre requêtes. CVE-2026-41712 décrit un défaut de configuration par défaut : si l''application développeur n''override pas explicitement la stratégie d''isolation par utilisateur, deux conversations distinctes peuvent partager le même bucket mémoire et un utilisateur peut récupérer le contexte d''un autre. C''est une fuite de données structurelle, équivalente fonctionnelle d''un IDOR sur l''historique LLM. CVE-2026-41713 est plus subtile : un utilisateur malveillant peut crafter une entrée qui, une fois stockée dans la mémoire conversationnelle, est ré-interprétée par le modèle au tour suivant comme une instruction système et altère le comportement de l''agent. C''est de l''injection de prompt persistante, exploitable même contre des sessions ultérieures et potentiellement contre d''autres utilisateurs si la mémoire est partagée.

Les correctifs sont disponibles depuis le 9 mai. Pour la branche 1.0.x, l''upgrade vers 1.0.7 ou supérieur est requis. Pour la branche 1.1.x, c''est 1.1.6 ou supérieur. Aucun mitigant officiel n''a été publié pour les organisations qui ne peuvent pas patcher dans la fenêtre de la semaine, ce qui place Spring AI dans une posture rare pour l''écosystème Spring : pas de workaround, l''upgrade est la seule option. La plus haute des trois, CVE-2026-41705, peut être atténuée en wrappant manuellement les appels MilvusVectorStore#doDelete avec une validation regex stricte sur les document IDs côté applicatif.

L''analyse de TheHackerWire souligne un point souvent négligé sur ces architectures : la base vectorielle Milvus n''est pas un composant de sécurité, c''est un moteur d''indexation et de recherche optimisé pour la performance. Les filtres Milvus n''ont jamais été conçus comme une frontière de confiance. Concevoir une API où des entrées utilisateur traversent un VectorStore Spring AI sans assainissement intermédiaire revient, conceptuellement, à construire une couche d''application qui concatène des entrées utilisateur dans une chaîne SQL : la même classe de risque, exprimée dans un nouveau formalisme.

L''écosystème Spring AI vit par ailleurs une période de tension produit notable. HeroDevs a publié le 30 avril une note rappelant que Spring AI 1.x atteint sa fin de support standard le 30 juin 2026, à peine un mois après la sortie prévue de Spring AI 2.0. Les organisations qui restent sur 1.x après cette date doivent souscrire à un programme de support étendu ou migrer en urgence. Cette CVE-2026-41705 publiée mi-mai accentue la pression : un patch sur 1.0.x est garanti aujourd''hui, mais la fenêtre de patching sur des versions vieillissantes va se refermer rapidement.

Côté détection, peu de signatures de scanners ASOC ou SCA sont disponibles à la publication de ces CVE. Les principaux outils du marché commencent tout juste à intégrer la base de données NVD pour ces identifiants. Snyk, Dependabot et Trivy ont publié leurs règles entre le 10 et le 12 mai. Les équipes opérant en environnement air-gapped ou avec des miroirs Maven internes doivent forcer la synchronisation pour récupérer les advisories à jour.

Impact et exposition

Toute application Java embarquant Spring AI 1.0.0 à 1.0.6 ou Spring AI 1.1.0 à 1.1.5 est exposée. Le périmètre concret dépend des composants utilisés : MilvusVectorStore concerne les déploiements RAG basés Milvus uniquement. Chat Memory concerne tout chatbot ou agent IA conversationnel construit sur Spring AI sans configuration explicite de l''isolation utilisateur. La gravité réelle se mesure à la sensibilité des données traitées : un assistant interne qui répond sur de la documentation publique a un impact limité ; un agent qui accède à des données client sous mémoire partagée mal configurée représente une fuite RGPD potentielle.

Recommandations

  • Mettre à jour Spring AI vers 1.0.7 (branche 1.0.x) ou 1.1.6 (branche 1.1.x) dans le sprint en cours, sans attendre la fin de support du 30 juin.
  • Auditer les classes consommatrices de MilvusVectorStore et ajouter une validation explicite des document IDs (UUID, regex stricte) avant tout appel doDelete.
  • Vérifier la configuration Chat Memory : s''assurer qu''une stratégie d''isolation par utilisateur est explicitement déclarée, ne pas se reposer sur le défaut.
  • Ajouter des règles de garde-fou côté prompt système pour ignorer les instructions provenant de la mémoire conversationnelle qui ressemblent à des directives système.
  • Tester la migration Spring AI 2.0 sur un environnement de pré-production avant le 28 mai pour anticiper la fin de support 1.x.

Spring AI Chat Memory en mémoire (non persistante) est-il concerné par CVE-2026-41712 ?

Oui, le défaut concerne la stratégie d''isolation par utilisateur, pas le backend de stockage. Une implémentation InMemoryChatMemory partagée entre plusieurs sessions sans configuration explicite d''un identifiant de conversation par utilisateur permet la même fuite. Le backend persistant (Postgres, Redis) n''aggrave que la fenêtre temporelle de la fuite.

Quelle alternative à MilvusVectorStore en attendant le patch ?

Spring AI propose plusieurs autres VectorStore (PgVectorStore, RedisVectorStore, ChromaVectorStore, ElasticsearchVectorStore). Aucun n''est annoncé comme vulnérable à la même classe d''injection dans cette publication, mais l''analyse de fond reste la même : toute concaténation directe d''entrée utilisateur dans une expression de filtre vectoriel doit être considérée comme un anti-pattern à supprimer, indépendamment du moteur cible.

Vos applications IA Spring exposent-elles des données sensibles ?

Ayi NEDJIMI accompagne les équipes Java IA dans la sécurisation des chaînes RAG : audit des VectorStore, isolation des contextes utilisateurs, durcissement des prompts système.

Demander un audit Spring AI