LMCache expose une RCE critique non corrigée via un simple message ZeroMQ sur les serveurs vLLM
Le 7 octobre 2026, JFrog révèle la faille CVE-2026-105192, une exécution de code à distance non authentifiée de gravité 9,8 dans LMCache, le cache qui accélère les serveurs LLM comme vLLM, sans correctif disponible. Si votre cache LMCache écoute sur une adresse routable, isolez-le immédiatement plutôt que d’attendre un patch.
7 octobre 2026. JFrog publie une faille qu’il note 9,8 sur 10, la plage critique. CVE-2026-105192. C’est le numéro d’une exécution de code à distance non authentifiée dans LMCache, le cache open source qui accélère les serveurs de LLM comme vLLM. Et il n’existe aucune version corrigée. Pourquoi c’est important : un seul message réseau adressé au cache suffit à exécuter des commandes avec les droits du processus — root sur les images officielles — et l’exemple Kubernetes fourni par le projet expose justement ce port sur toutes les interfaces.
Un message ZeroMQ suffit pour exécuter du code
La faille vit dans le mode multiprocessus de LMCache. Dans ce mode, le cache ne tourne plus à l’intérieur du processus vLLM : il devient un serveur autonome que les workers atteignent via la bibliothèque de messagerie ZeroMQ. C’est ce serveur qui porte la vulnérabilité.
Le socket ZeroMQ ouvert pour que les workers s’enregistrent et partagent les données mises en cache n’a aucune authentification. Un type de message est désérialisé avec pickle, le format de sérialisation natif de Python. Or pickle n’est pas un format de données : c’est un format d’exécution. Il peut embarquer du code arbitraire et l’exécuter au moment même où il est décodé. Le serveur dépaquette le message avant de vérifier son type, pendant qu’il en lit encore les arguments. Résultat : un message forgé par l’attaquant fait tourner son code avec les privilèges du processus LMCache.
Sur les images de conteneurs officielles, ce processus s’exécute en root, précise JFrog. La chaîne complète tient donc en une étape : atteindre le socket, envoyer un message pickle piégé, obtenir un shell root sur la machine qui héberge le cache.
Le périmètre réel tient à un seul réglage
Une nuance change tout pour l’exposition réelle. Par défaut, le serveur multiprocessus n’écoute que sur la boucle locale (127.0.0.1) : une autre machine ne peut pas l’atteindre. Il devient joignable dès qu’un opérateur le démarre sur une adresse routable, ce qui est précisément le cas des déploiements multi-nœuds où plusieurs machines partagent un même cache.
C’est là que la documentation joue contre l’utilisateur. L’exemple Kubernetes fourni par LMCache lui-même démarre le serveur en écoutant sur toutes les interfaces réseau. Un opérateur qui suit le manifeste de référence sans l’adapter expose donc le port à l’ensemble du cluster — et, selon la topologie, à tout ce qui peut joindre ce cluster.
Le périmètre des versions concernées est large : CVE-2026-105192 affecte LMCache depuis la 0.3.9 (octobre 2025) jusqu’à la 0.5.5, la dernière version stable, et reste présente dans les release candidates 0.5.6 comme dans la branche de développement. Aucune version corrigée n’existe au moment de la publication.
pickle, encore une fois
Le défaut racine — confier à pickle des données issues d’un socket non authentifié — n’a rien d’inédit. C’est le même mécanisme que les chercheurs ont relevé en novembre 2025 dans un ensemble de failles d’autres frameworks d’inférence, regroupées sous le nom ShadowMQ. La leçon est ancienne et unanime : ne jamais désérialiser avec pickle une donnée qui peut venir de l’extérieur, quelle que soit la couche qui la transporte.
Ce qui rend LMCache vulnérable en pratique, c’est moins la technicité de la faille que son invisibilité. LMCache n’a publié aucun avis de sécurité. L’advisory de JFrog ne fournit aucun moyen de déterminer si un serveur a déjà été attaqué : pas d’indicateur de compromission, pas de signature réseau, pas de journal à inspecter. Une équipe qui découvre la faille aujourd’hui ne peut pas savoir si son cache a déjà servi de porte d’entrée.
Un écosystème qui bouge autour
La faille n’est pas isolée. Le 6 octobre 2026, la veille de la divulgation, un compte GitHub a déposé six signalements supplémentaires sur LMCache. Ils allèguent un accès non authentifié aux données en cache appartenant à d’autres locataires, ainsi que l’exposition de plusieurs services réseau qui exécutent des commandes sans connexion. Ces rapports reposent sur des preuves de concept, sans CVE, sans confirmation des mainteneurs et sans correctif. L’un d’eux pointe un défaut depuis corrigé : le serveur HTTP d’administration qui écoutait sur toutes les interfaces en 0.5.5 n’écoute plus que sur la boucle locale dans les release candidates 0.5.6.
Une faille voisine dans vLLM est, elle, déjà refermée. Avant la version 0.30.0 (publiée le 22 septembre 2026), une requête unique portant une valeur cache_salt malformée pouvait faire planter le moteur sur les déploiements utilisant le connecteur multiprocessus de LMCache. Ce déni de service, CVE-2026-105756, est noté 6,5 et ne permet pas l’exécution de code. Il montre néanmoins que la surface d’attaque se déplace vite autour des couches d’accélération d’inférence.
Ce qu’il faut faire maintenant
En l’absence de patch, la protection est architecturale, pas logicielle. Premièrement, ne liez jamais le serveur multiprocessus à une adresse routable : gardez-le sur 127.0.0.1 ou, au pire, sur un réseau de cluster de confiance. Deuxièmement, auditez vos manifestes : si vous avez repris l’exemple Kubernetes de LMCache tel quel, votre serveur écoute probablement sur 0.0.0.0. Troisièmement, appliquez un pare-feu qui restreint les hôtes autorisés à joindre le port — en gardant à l’esprit que ce filtre réduit le risque sans le supprimer, puisque tout hôte encore capable d’ouvrir une connexion peut exécuter du code.
Pour un déploiement mono-machine classique — LMCache exécuté dans le processus vLLM, cache non exposé — le port n’est jamais ouvert et l’exposition est nulle. Le risque se concentre sur les déploiements multi-nœuds qui partagent un cache entre machines, et sur les images officielles qui courent en root.
Pourquoi la couche d’inférence devient une cible
Le cache est le dernier maillon auquel on pense. LMCache n’est pas le modèle — c’est la plomberie qui l’alimente, et c’est précisément ce qui la rend dangereuse. Les composants d’accélération d’inférence — caches KV, routeurs de requêtes, ordonnanceurs — se déploient à la hâte, avec une revue de sécurité bien inférieure à celle du pare-feu ou du plan de contrôle web. Leur métier est la performance, et la performance s’obtient souvent en supprimant les étapes qui ralentissent — l’authentification en premier.
Le mode multiprocessus de LMCache en est l’illustration exacte. Séparer le cache du processus vLLM accélère l’inférence en partageant un cache entre workers, mais cela crée aussi un service réseau — un socket ZeroMQ — qui n’existait pas auparavant. Un service réseau sans authentification est une cible ; un service réseau qui exécute du code via pickle est une porte dérobée. La combinaison des deux fait de cette plomberie un point d’entrée aussi sérieux qu’un serveur web exposé, mais sans la visibilité habituelle : pas de WAF, pas de logs applicatifs, pas d’alerte SIEM dédiée.
Ce qui aggrave la situation, c’est la concentration des privilèges. Les images officielles exécutent LMCache en root, ce qui signifie qu’un message forgé n’obtient pas seulement un accès au cache — il obtient la machine entière, avec la possibilité de pivoter vers les modèles, les données qui transitent par le cluster d’inférence et les secrets que les workers partagent avec le cache.
Verdict
Si votre cache LMCache écoute sur une adresse routable, traitez la machine comme potentiellement compromise : isolez-la, coupez le port, et planifiez un ré-examen dès qu’un correctif sortira, car JFrog n’offre aucun moyen de prouver qu’elle n’a pas déjà été attaquée. Si vous déployez LMCache en mono-processus dans vLLM, vous n’êtes pas exposé à CVE-2026-105192 — mais surveillez les annonces, car les six signalements du 6 octobre suggèrent que d’autres surfaces d’attaque restent à clarifier. Dans tous les cas, bannissez pickle de tout chemin qui croise un socket non authentifié : c’est la règle qui, appliquée en amont, aurait rendu cette faille inoffensive.