Spring AI : trois CVE HIGH menacent les apps Java IA

Les faits

VMware a publié le 9 mai 2026 un bulletin de sécurité consacré à Spring AI, le framework Java officiel de l'écosystème Spring dédié à l'intégration des modèles de langage. Ce lot Spring AI CVE 2026 rassemble trois vulnérabilités classées HIGH qui frappent le cœur même des architectures RAG et des mécanismes de chat persistant : injection de contexte via les vector stores, désérialisation non maîtrisée des historiques de conversation et contournement des filtres de métadonnées. Les trois failles affectent aussi bien la branche stable 1.0.x que la branche de pré-version 1.1.x, ce qui place la quasi-totalité du parc applicatif Java exposé aux LLM en situation de risque immédiat. Pour les équipes ayant industrialisé des assistants internes ou des moteurs de recherche augmentés, la mise à jour n'est pas une option mais une urgence opérationnelle.

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.