L’architecture distribuée de LMCache présente une vulnérabilité critique qui peut permettre à un client réseau non authentifié d’exécuter du code par le biais d’une désérialisation Python non sécurisée. La faille, CVE-2026-105192, a reçu un score CVSS v3.1 de 9.8 CRITICAL.
JFrog, l’autorité de numérotation CVE responsable de cette faille, a publié et mis à jour sa fiche CVE le 7 octobre 2026. Les chercheurs en sécurité de l’entreprise ont également divulgué la vulnérabilité ce jour-là et attribué sa découverte à Yuval Moravchick.
Le risque dépend de la configuration. Par défaut, LMCache limite le transport concerné à localhost, mais les opérateurs peuvent l’exposer sur une adresse routable pour les déploiements multi-nœuds. Au moment de la divulgation, aucun correctif pour LMCache n’avait été identifié et aucun élément vérifié ne montrait que des attaquants avaient exploité la faille dans des systèmes en production.
Un message réseau atteint pickle.loads avant toute authentification
LMCache est un logiciel de mise en cache open source conçu pour accélérer les systèmes d’inférence de grands modèles de langage, comme vLLM. Le composant vulnérable est son mode multiprocessus, également appelé mode distribué, dans lequel LMCache fonctionne comme un serveur de cache distinct et les workers communiquent avec lui via ZeroMQ.
Selon la fiche du programme CVE, le serveur ouvre un socket ZeroMQ ROUTER utilisé par les workers pour s’enregistrer et échanger des blocs de cache KV. Ce socket n’authentifie pas les clients.
Les messages sont encodés avec msgpack. Lors du décodage, le code d’extension 1 est transmis à DeviceIPCWrapper.Deserialize, qui appelle la fonction Python pickle.loads sur des données contrôlées par l’expéditeur. Point essentiel : la désérialisation a lieu alors que le serveur traite encore les arguments de la requête, avant l’exécution du gestionnaire de message concerné.
Un attaquant capable d’atteindre le transport peut donc envoyer un seul message ZeroMQ DEALER spécialement conçu et déclencher l’exécution de code avec les privilèges du compte qui exécute LMCache. Aucun identifiant ni aucune interaction de l’utilisateur n’est nécessaire.
Le vecteur attribué est le suivant :
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
La fiche classe la faille à la fois comme CWE-306, absence d’authentification pour une fonction critique, et CWE-502, désérialisation de données non fiables.
L’exposition au réseau dépend de la manière dont les opérateurs configurent le port 5555
Le transport concerné utilise le port 5555 par défaut. Il n’écoute que sur localhost, sauf si un opérateur lui fournit une adresse routable à l’aide de --host, ce qui permet aux workers d’autres nœuds de se connecter.
Par conséquent, une installation conservant la liaison locale par défaut n’est pas accessible à distance depuis un autre hôte par cette interface. L’exposition change si le service est lié à une adresse du cluster, à toutes les interfaces réseau ou à un autre point de terminaison accessible depuis le réseau.
Le rapport initial indique que l’exemple de déploiement Kubernetes de LMCache démarre le serveur sur toutes les interfaces réseau. Il précise également qu’une instance de LMCache intégrée à un processus vLLM unique n’ouvre pas le port concerné.
Selon JFrog, les images de conteneur officielles de LMCache exécutent le processus en tant que root. Une exploitation réussie dans ces images pourrait donc permettre d’exécuter du code avec les privilèges root dans l’environnement où le processus fonctionne. Cela ne s’applique pas automatiquement aux installations configurées pour exécuter LMCache avec un compte moins privilégié et ne permet pas de déterminer quelles ressources de l’hôte un conteneur donné peut atteindre.
Aucune exploitation dans la nature n’a été vérifiée dans les fiches citées. Le chemin technique permet une exécution de code à distance lorsque le socket est accessible, mais ce constat ne constitue pas une preuve de compromission réelle.
Les fiches de version divergent sur l’étendue complète des versions de LMCache
La fiche CVE officielle indique que LMCache 0.3.9 est vulnérable, sans préciser de limite supérieure. Les références qu’elle cite pointent vers du code vulnérable dans v0.3.9 et v0.5.5.
L’article d’actualité mentionne une plage plus large : les versions comprises entre 0.3.9 et 0.5.5, ainsi que les versions candidates 0.5.6 et la branche de développement. Il présente 0.5.5 comme la dernière version stable et indique que la version 0.3.9 est sortie en octobre 2025.
Ces affirmations ne reposent pas sur le même niveau de preuve. La fiche de l’autorité de numérotation confirme que la version 0.3.9 est concernée, tandis que l’étendue plus large aux versions et branches est rapportée par l’article, et non établie dans une déclaration exhaustive des versions vulnérables de la fiche CVE fournie.
Aucune version corrigée de LMCache n’avait été identifiée au moment de la divulgation. La fiche CVE ne mentionne aucune version corrigée et, selon l’article, aucun correctif n’était encore disponible le 7 octobre 2026.
Isoler le réseau est la première mesure de protection
Les recommandations provisoires de JFrog, rapportées dans l’article, visent à empêcher les systèmes non fiables d’accéder au transport ZeroMQ :
- Ne liez pas le serveur multiprocessus à une adresse routable tant qu’aucune version corrigée n’est disponible.
- Laissez le service sur localhost lorsqu’un fonctionnement distribué n’est pas nécessaire.
- Si des workers distants doivent se connecter, limitez l’accès à un réseau de cluster de confiance.
- Filtrez le port 5555 au moyen de règles de pare-feu et n’autorisez que les pairs nécessaires.
Le filtrage par pare-feu réduit la surface d’attaque accessible, mais ne corrige pas le problème de désérialisation non sécurisée. Tout hôte autorisé ou compromis qui peut se connecter au socket pourrait toujours être en mesure d’envoyer le message malveillant.
Les opérateurs devraient également vérifier quel compte exécute le processus LMCache et limiter ses privilèges. Cela réduit les conséquences potentielles, mais ne remplace pas la correction du code vulnérable.
L’article indique que l’avis de JFrog ne fournissait aucune procédure pour déterminer si la faille avait déjà été exploitée. Les documents cités ne contiennent pas non plus d’indicateurs de compromission ni de requête d’investigation concernant CVE-2026-105192. Cette observation se limite aux informations disponibles dans les articles cités et ne permet pas d’affirmer qu’aucune consigne n’existe ailleurs.
Une faille distincte dans vLLM peut arrêter EngineCore
Un problème connexe, mais techniquement distinct, concerne les déploiements de vLLM utilisant le connecteur KV intégré LMCache-MP. CVE-2026-105756 permet à une valeur cache_salt malformée de déclencher une exception non interceptée et d’arrêter EngineCore.
Cette vulnérabilité a un score CVSS v3.1 de 6.5 et est considérée comme modérée :
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Elle est classée comme CWE-20, validation incorrecte des entrées, et CWE-248, exception non interceptée. Contrairement à la RCE de LMCache, son vecteur indique que des privilèges faibles sont nécessaires et que l’impact se limite à la disponibilité.
Les modèles compatibles avec l’API OpenAI pour les requêtes Completions, Chat Completions et Responses acceptent toute valeur cache_salt non vide, mais IPCCacheServerKey, utilisé en aval par LMCache-MP, impose des restrictions supplémentaires. Il rejette les valeurs de plus de 128 caractères ou contenant @, /, \ ou NUL.
Ces contraintes n’étaient pas appliquées avant que la valeur ne parvienne à la recherche de cache du scheduler. Selon l’avis de sécurité GitHub, une valeur rejetée déclenche une ValueError qui n’est interceptée ni au niveau du connecteur ni à celui du scheduler. EngineCore traite alors l’exception comme fatale, ce qui perturbe le service pour les utilisateurs connectés en parallèle. L’avis donne cache_salt="/" comme exemple.
Le problème a été confirmé sur vLLM 0.25.1, commit 752a3a504485, et ne concerne que les installations où le connecteur LMCache-MP, activé sur option, est utilisé. Ce connecteur nécessite lmcache >= 0.4.4.
La description de la NVD et la plage de versions indiquée dans l’avis général désignent comme vulnérables les versions antérieures à 0.30.0 et indiquent que 0.30.0 corrige le problème. Toutefois, un autre champ de l’avis indique que les versions corrigées sont >= 30.0.0. Cette valeur incohérente ne doit pas être considérée comme équivalente sans vérification ; les opérateurs devraient confirmer la version du paquet qu’ils déploient. L’avis a été publié le 23 septembre 2026 et, selon l’article, vLLM 0.30.0 est sorti le 22 septembre.
D’autres signalements concernant LMCache restent à confirmer
L’article décrit également six autres signalements de sécurité concernant LMCache, publiés par un compte GitHub le 6 octobre 2026. Ils font état d’un accès inter-locataires aux données mises en cache et d’un accès non authentifié à des services réseau capables d’exécuter des commandes.
Ces signalements n’ont reçu aucun identifiant CVE, n’ont pas été confirmés par les responsables de la maintenance et ne mentionnent aucun correctif dans les articles cités. Ils reposent sur des preuves de concept et sont distincts de CVE-2026-105192.
L’un de ces signalements affirme qu’un serveur HTTP d’administration écoutait sur toutes les interfaces dans la version 0.5.5, tandis que les versions candidates 0.5.6 le limiteraient à localhost. Tant que les responsables de la maintenance n’ont pas validé les affirmations sous-jacentes, ces signalements ne doivent pas être présentés comme des vulnérabilités confirmées de LMCache.
Le schéma non sécurisé à l’origine de CVE-2026-105192 rappelle l’utilisation de la messagerie non authentifiée avec Python pickle, étudiée par des chercheurs sous le nom ShadowMQ en novembre 2025. Les articles ne permettent pas d’établir que ces découvertes antérieures et LMCache partagent du code ou une origine commune.
