Une faille dans LMCache expose certains serveurs IA. Le périmètre compte
La faille signalée par JFrog concerne le canal réseau d’un mode de LMCache. Elle ne touche pas de la même façon toutes les installations de serveurs IA.
JFrog publie le 7 octobre 2026 une alerte critique sur LMCache. La faille CVE-2026-105192 permet l’exécution de code sans authentification dans une configuration réseau précise. Ce composant accélère les serveurs de modèles de langage.
Un cache derrière les réponses du modèle
La documentation officielle de LMCache décrit une couche qui conserve et réutilise des calculs intermédiaires des modèles. Le cache peut passer de la mémoire du processeur graphique à d’autres supports. Plusieurs requêtes ou moteurs peuvent ainsi réutiliser un travail déjà effectué. L’objectif annoncé consiste notamment à réduire l’attente avant le premier élément de réponse.
Ce cache ne correspond pas simplement à une liste de réponses finales. Il garde des états de calcul utiles au traitement du contexte. La documentation distingue aussi un mode où LMCache fonctionne dans un service séparé. Des moteurs comme vLLM lui adressent alors leurs demandes. Cette organisation facilite le partage des ressources mais ajoute des échanges entre programmes.
Une exposition qui dépend du déploiement
Selon JFrog, le canal ZeroMQ du mode multiprocessus n’authentifie pas ses interlocuteurs. Il reste local par défaut. L’accès depuis une autre machine apparaît quand l’opérateur configure une adresse joignable sur le réseau. La note de gravité de 9,8 sur 10 concerne cette configuration. Le bulletin ne décrit donc pas toutes les installations comme également exposées.
JFrog précise que LMCache intégré dans un seul processus vLLM n’ouvre pas ce port. Le numéro de version ne suffit donc pas à décrire l’exposition réelle.
Quand lire des données peut exécuter du code
Le chemin vulnérable traite certaines données reçues avec pickle. La documentation de Python avertit explicitement que ce format ne convient pas aux données non fiables. Reconstruire un objet depuis ce format peut déclencher du code. Ce comportement explique pourquoi la confiance dans l’émetteur forme une frontière de sécurité.
Une sérialisation transforme une structure de programme en données transportables. L’opération inverse la reconstruit. Tous les formats ne présentent pas les mêmes propriétés. Python explique notamment que lire du JSON ne crée pas en soi cette possibilité d’exécuter du code arbitraire. Choisir un format plus sûr ne dispense toutefois pas de contrôler les accès et les données. Ces protections répondent à des questions différentes.
Une alerte datée et un état à suivre
Le bulletin JFrog décrit le chemin vulnérable depuis la version 0.3.9 et indique l’absence de version corrigée au 7 octobre. Lors de notre contrôle du 9 octobre, le registre PyPI présente toujours 0.5.5 comme version publiée courante. Ça ne prouve pas que chaque modification en développement conserve le défaut.
La page des avis de sécurité du dépôt officiel n’affiche pas d’avis publié au même contrôle. Cette absence ne constitue ni un démenti des chercheurs ni une preuve de correction. Les versions de développement et les versions stables doivent rester distinctes. Une nouvelle publication devra préciser explicitement le changement qui traite cette faille.
JFrog recommande de limiter l’accès réseau au canal concerné. Les chercheurs précisent qu’un pare-feu réduit les interlocuteurs possibles. Un interlocuteur qui peut encore se connecter conserve toutefois la possibilité d’exploiter le défaut.
La sécurité se joue aussi sous l’interface
Cette affaire illustre une distinction utile. Le modèle peut refuser une demande dangereuse tandis qu’un composant de son service reçoit des données non fiables. Le premier contrôle porte sur le comportement de l’assistant. Le second protège le programme qui le fait fonctionner. Améliorer un de ces contrôles ne remplace pas l’autre.
L’alerte décrit une possibilité technique dans un périmètre précis. Les sources consultées ne démontrent pas une campagne d’exploitation généralisée. Garder cette différence évite de transformer une vulnérabilité documentée en récit d’incident qui n’a pas été établi.
Notre article sur les conteneurs Microsoft MXC et les permissions des agents explique une autre frontière entre le raisonnement de l’IA et l’exécution de ses outils.