LMCache expose une vulnérabilité d'exécution de code à distance non authentifiée en mode multi‑processus, affectant la couche de cache des grands modèles

Le 8 octobre 2026, les sites iThome et JFrog Security Research ont publié simultanément un rapport détaillant la découverte d’une vulnérabilité critique dans LMCache lorsqu’il fonctionne en mode multi‑processus, c’est‑à‑dire distribué. Cette faille, identifiée sous le numéro CVE‑2026‑105192, permet une exécution de code à distance non authentifiée et a reçu une note CVSS v3.1 de 9,8, la classant dans la catégorie « critique ». Les chercheurs ont souligné que la gravité de la vulnérabilité réside dans le fait qu’elle ne nécessite aucune authentification préalable et peut être exploitée dès que le service expose son port de communication. La divulgation a été faite le 7 octobre 2026, mais les impacts restent visibles à ce jour, affectant les déploiements actuels de LMCache.

Vue d'ensemble de la vulnérabilité

Le défaut a été rendu public par l’équipe de recherche de JFrog (référence interne JFSA‑2026‑001694382) le 7 octobre 2026. Il concerne toutes les versions de LMCache à partir de la 0.3.9, y compris les versions officielles 0.5.5, la version de test 0.5.6rc3 et les branches de développement, aucune d’entre elles n’ayant reçu de correctif à ce jour. La racine du problème se situe dans le socket ZeroMQ de type ROUTER que LMCache ouvre pour partager le cache KV entre processus. Ce socket écoute par défaut sur le port TCP 5555 et, de manière alarmante, aucune forme d’authentification n’est activée – ni CURVE, ni ZAP, ni mot de passe, ni HMAC – laissant ainsi le canal totalement ouvert aux connexions non autorisées.

Détails techniques

Dans un déploiement à plusieurs nœuds, l’utilisateur doit fournir une adresse routable via le paramètre `--host`. Dès que ce paramètre est utilisé, le socket ZeroMQ passe d’une liaison exclusive à localhost à une adresse accessible depuis l’extérieur. LMCache utilise le format msgpack pour encoder les messages échangés. Le code d’extension 1 de msgpack est mappé vers la fonction `DeviceIPCWrapper.Deserialize`, qui, à son tour, invoque directement `pickle.loads` de la bibliothèque standard Python. Cette désérialisation intervient alors que le serveur traite encore le paramètre `REGISTER_KV_CACHE`, avant même que tout gestionnaire de requête ne soit engagé, ce qui autorise un attaquant à injecter une charge utile pickle malveillante et à exécuter du code Python arbitraire dans le contexte du processus LMCache.

Processus d'attaque

Un exploitateur n’a besoin que d’envoyer un message msgpack spécialement forgé vers le port 5555 ouvert. La charge utile pickle contenue dans ce message peut, par exemple, écrire un fichier tel que `/tmp/zmq_pwn`. Après l’écriture, le serveur génère un message d’erreur de type log, confirmant que le code a bien été exécuté dans le processus LMCache. Les images officielles de conteneur démarrent LMCache avec les privilèges root par défaut ; ainsi, si l’exploitation réussit, l’attaquant obtient immédiatement les droits root à l’intérieur du conteneur, ce qui lui permet d’influencer d’autres services hébergés sur le même hôte.

Portée affectée

Les versions concernées comprennent la série 0.3.9, toutes les versions 0.4.x et la série 0.5.x. De plus, les images de conteneur officielles distribuées par le projet n’ont pas été corrigées. iThome a précisé que le port ZeroMQ n’est activé que lorsque LMCache fonctionne comme service multi‑processus autonome ; lorsqu’il est intégré uniquement à l’intérieur d’un processus vLLM, le port n’est pas lancé, ce qui évite l’exposition de la faille. Par défaut, ZeroMQ se lie à localhost, rendant le port inaccessible aux attaquants distants, sauf si un administrateur modifie explicitement le paramètre `--host` pour y placer une adresse routable.

Atténuation et recommandations

JFrog recommande de restreindre immédiatement l’adresse de liaison du service multi‑processus à localhost et de bloquer le port TCP 5555 à l’aide d’un pare‑feu ou de politiques réseau du cluster. Il est également conseillé de ne jamais utiliser une adresse IP routable via le paramètre `--host` tant qu’un correctif officiel n’est pas disponible. À plus long terme, il faut repenser la couche de transport afin d’éliminer l’usage de pickle pour la désérialisation de données réseau non vérifiées, en adoptant un format de sérialisation sécurisé (par exemple JSON ou protobuf). Enfin, il est crucial d’ajouter une authentification au socket ZeroMQ, telle que CURVE ou HMAC, pour empêcher les connexions non autorisées.

Suivi et perspectives

À la date du 8 octobre 2026, le fournisseur n’a publié aucun correctif ni d’image de conteneur mise à jour désactivant la désérialisation dangereuse. Le calendrier de correction reste donc indéterminé, tout comme la disponibilité de correctifs dans les distributions tierces. Les environnements qui ont conservé la liaison par défaut à localhost ou qui ont isolé leurs conteneurs du réseau non fiable ne sont pas directement exposés à une attaque distante, mais les utilisateurs internes ou les machines déjà compromises pourraient toujours exploiter cette faille pour obtenir les privilèges les plus élevés à l’intérieur du conteneur. La communauté attend donc des mises à jour de sécurité officielles pour atténuer définitivement le risque.