Le 7 octobre 2026, JFrog a révélé une vulnérabilité critique dans LMCache, un logiciel open-source qui accélère les serveurs de LLM comme vLLM. La CVE-2026-105192 obtient une note CVSS 9.8 lorsque le serveur multiprocessus est lié à une adresse routable, et aucune version corrigée n'est encore disponible. Un attaquant non authentifié pouvant accéder au port ZeroMQ peut exécuter du code en tant qu'utilisateur du processus LMCache — souvent root sur les images de conteneurs officielles.
En mode multiprocessus, LMCache fonctionne comme un serveur de cache autonome auquel les travailleurs de LLM accèdent via ZeroMQ. Par défaut, il n'écoute que sur localhost. Il devient accessible depuis d'autres hôtes lorsque les opérateurs définissent une adresse routable — une pratique courante dans les clusters multi-nœuds. L'exemple officiel du projet Kubernetes démarre le serveur en écoute sur toutes les interfaces. LMCache intégré dans un seul processus vLLM n'ouvre pas le port du tout.
Le socket ZeroMQ ne dispose d'aucune authentification. Un type de message est décompressé avec le module Python `pickle`, qui peut transporter et exécuter du code lors du décodage. Le serveur décompresse les arguments en lecture avant de vérifier le type de message, ce qui permet à un message malveillant d'exécuter immédiatement le code de l'expéditeur. Les versions affectées sont : 0.3.9 (octobre 2025) jusqu'à 0.5.5 (la dernière version stable), ainsi que les versions candidates à la sortie 0.5.6 et la branche de développement. Découvreur : Yuval Moravchick, JFrog Security Research.
Avant qu'un correctif ne soit publié, JFrog conseille de ne pas attribuer d'adresse routable au serveur multiprocessus et de garder le port sur la machine locale ou un réseau de cluster de confiance. Un pare-feu réduit les risques, mais ne les élimine pas — tout hôte pouvant toujours se connecter peut exécuter du code. LMCache n'a pas publié son propre avis de sécurité, et JFrog ne fournit aucun moyen de déterminer si un serveur a déjà été attaqué.
La veille de la publication de la CVE, six rapports supplémentaires sur GitHub ont évoqué un accès non authentifié à un cache multi-tenants et des services réseau sans connexion — sans CVE, sans confirmation du mainteneur. Une vulnérabilité de type DoS liée à vLLM (CVE-2026-105756, CVSS 6.5) dans le connecteur multiprocessus LMCache est déjà corrigée dans la version vLLM 0.30.0. Le schéma — un socket non authentifié vers pickle — rappelle les conclusions de ShadowMQ concernant les vulnérabilités dans les frameworks d'inférence d'IA en novembre 2025.
Pour les organisations exploitant des agents IA et des infrastructures de LLM en production, il s'agit d'une question d'exposition immédiate : un serveur de cache accidentellement lié à 0.0.0.0 devient une surface d'exécution à distance non corrigée (RCE). Passez en revue chaque déploiement de vLLM/LMCache, retirez les liaisons routables et segmenter les réseaux de cluster.
Les niveaux de cache des LLM sont souvent négligés dans la gestion des vulnérabilités car ils sont considérés comme des « composants internes de performance » plutôt que comme une surface d’attaque. En pratique, ils se trouvent à côté des nœuds GPU, fonctionnent fréquemment en tant que root dans des conteneurs et peuvent accéder aux modèles, aux prompts et parfois aux secrets injectés via des variables d’environnement. Une RCE via pickle à cet endroit n’est pas seulement une attaque par déni de service (DoS) — elle peut signifier le vol des poids de modèle, une injection de prompt contre d’autres travailleurs et une escalade dans le cluster.
La leçon de ShadowMQ en 2025 reste valable : les formats de sérialisation exécutant du code ne doivent pas être placés derrière des sockets non authentifiés.
Les labs AI nordiques, les entreprises SaaS et les pilotes du secteur public testant vLLM devraient particulièrement examiner les Helm charts et les modules Terraform qui ont copié l’exemple LMCache Kubernetes. Écouter par défaut sur toutes les interfaces est pratique en laboratoire, mais dangereux en production. Placez ZeroMQ derrière un NetworkPolicy, un mTLS, ou au moins avec `hostNetwork=false` et un CIDR de pod strict. Documentez quelle équipe est responsable du nœud de cache — sinon, les correctifs deviendront un problème de « quelqu’un d’autre » lorsque les alertes de vulnérabilité arriveront enfin.
**Que doivent faire les responsables IT et sécurité maintenant**
Inventaire LMCache 0.3.9–0.5.5 (et versions RC). Si le mode multiprocessus est utilisé : assurez-vous que ZeroMQ n’écoute que sur le localhost ou les réseaux privés de cluster ; retirez les liaisons routables. Mettez à jour vLLM à ≥0.30.0 pour corriger la CVE-2026-105756. Surveillez les processus/connexions inattendus depuis les conteneurs LMCache. Prévoyez d’appliquer la correction du fournisseur dès sa sortie — en attendant, l’isolement réseau reste la seule mesure efficace.
De plus, réexaminez si pickle est utilisé dans d’autres services AI internes et remplacez-le par des protocoles plus sûrs si possible.