Votre cluster d'inférence LLM écoute sur le port 5555 — et n'importe quoi sur ce réseau peut exécuter du code en tant que root
Il y a deux semaines, l'équipe de sécurité de JFrog a divulgué une vulnérabilité d'un score CVSS de 9.8 — la deuxième note la plus élevée possible. Aucun correctif. Un exploit de preuve de concept public. Et le logiciel affecté se situe directement dans la couche d'inférence de l'une des piles de service LLM open source les plus populaires au monde.
La vulnérabilité est CVE-2026-105192, et elle se trouve dans LMCache : la couche de cache clé-valeur distribuée qui alimente vLLM, le moteur d'inférence open source exécuté sur des milliers de clusters de production en ce moment même.
Il ne s'agit pas d'une faille théorique. C'est un chemin d'exécution de code à distance non authentifié, divulgué le 7 octobre 2026 sous l'avis JFSA-2026-001694382, et à l'heure où nous écrivons ces lignes, aucune version corrigée n'existe.
Ce que fait réellement LMCache — et pourquoi il est partout
Si vous exécutez de l'inférence LLM à grande échelle, vous avez probablement déjà rencontré LMCache. C'est un cache clé-valeur distribué qui stocke et réutilise des blocs de cache KV (les états d'attention intermédiaires qui dominent la mémoire et la latence de l'inférence LLM). vLLM — le moteur d'inférence que des organisations allant de Hugging Face aux entreprises du Moyen-Orient utilisent pour servir des modèles à poids ouverts et affinés — intègre LMCache comme couche de mise en cache externe dans ses déploiements multi-nœuds.
L'idée : lorsqu'un processus worker sur le nœud A calcule un bloc KV, il peut le partager avec les processus worker du nœud B au lieu de le recalculer. En mode distribué, LMCache ouvre un socket ZeroMQ ROUTER — par défaut sur le port 5555 — afin que les processus worker puissent s'enregistrer et échanger des blocs de cache entre machines.
C'est un chemin rapide pour le service LLM. Et il n'a aucune authentification.
La vulnérabilité : un message de cache qui exécute votre code
Voici la faille, décomposée :
- Le transport multiprocessus de LMCache parle MessagePack avec le code d'extension 1 pour
DeviceIPCWrapper - Lors du décodage, le hook d'extension dans
lmcache/v1/multiprocess/custom_types.pytransmet les données intégrées àDeviceIPCWrapper.Deserialize - Cette fonction appelle
pickle.loads— la désérialisation binaire non sécurisée de Python - La désérialisation se produit pendant que le serveur traite les arguments de
REGISTER_KV_CACHE, avant l'exécution du gestionnaire de requêtes
En d'autres termes : tout message qui atteint le serveur de cache sur le port 5555 peut déclencher l'exécution de code sur l'hôte, sous l'utilisateur avec lequel le processus LMCache s'exécute.
Le PoC public de JFrog lui-même (research.jfrog.com) le démontre de bout en bout :
- Un attaquant envoie un message MessagePack multipart conçu pour le port 5555 de n'importe quel nœud LMCache joignable
- La charge utile pickle intégrée contient un objet
DeviceIPCWrappermalveillant - Lorsque le serveur le désérialise, la reconstruction du pickle exécute une commande système
- Le PoC écrit la sortie de
iddans/tmp/zmq_pwn - Le serveur journalise alors une erreur de type — le gestionnaire reçoit la valeur de retour de la commande au lieu du wrapper attendu. Trop tard.
Le PoC confirme l'exécution. Le conteneur s'exécute en tant que root.
Qui est concerné
Le chemin de décodage vulnérable a été introduit dans LMCache 0.3.9 et reste présent dans toutes les versions jusqu'à 0.5.5, toutes les release candidates jusqu'à 0.5.6rc3, et la branche de développement examinée au 7 octobre. Cela signifie :
- Tout déploiement distribué vLLM + LMCache sur les versions 0.3.9 à 0.5.6rc3
- Les déploiements utilisant le drapeau
--hostpour se lier à une IP routable (pas seulement localhost) - Les clusters de production en configurations multi-GPU ou multi-nœuds où les nœuds de cache sont joignables sur le réseau
JFrog a explicitement limité le score de 9.8 à la configuration joignable sur le réseau. Un déploiement vLLM sur un seul hôte, où LMCache n'ouvre pas le port concerné, n'est pas vulnérable. Mais si vous avez activé l'inférence multi-nœuds avec des adresses routables — et la plupart des clusters LLM réels l'ont fait — vous êtes concerné.
Ce que vous devriez faire dès maintenant
Il n'existe aucune version corrigée. Voici le manuel de mitigation :
- Restreindre le port 5555 : appliquez des règles de pare-feu pour garantir que seules les IP spécifiques des nœuds de cache de votre cluster LLM puissent atteindre le port 5555. Bloquez tout le reste.
- Revenir à une liaison localhost : si vous pouvez reconfigurer temporairement votre déploiement pour utiliser LMCache uniquement en localhost, faites-le. Vous perdez le partage de cache entre nœuds mais éliminez entièrement la surface d'attaque.
- Remplacer pickle par un sérialiseur sûr : la recommandation à plus long terme de JFrog est de remplacer la désérialisation réseau basée sur pickle par un format de sérialisation sûr (le système de types natif de MessagePack, JSON ou protobuf) et d'authentifier le transport ZeroMQ avec CURVE, ZAP ou une vérification HMAC par message.
- Épingler les versions de LMCache et surveiller : si vous êtes sur 0.5.x, surveillez le suivi des versions pour une version corrigée. Tant qu'elle n'est pas disponible, les mitigations ci-dessus constituent votre seule défense.
- Auditer la topologie de votre cluster : vérifiez quels nœuds exécutent LMCache avec un drapeau
--hostroutable. Chacun d'eux est un point d'extrémité RCE non authentifié potentiel pour tout ce qui peut atteindre le port 5555 sur le réseau interne.
La vue d'ensemble : l'infrastructure IA est désormais votre surface d'attaque
CVE-2026-105192 dans LMCache n'est pas la première vulnérabilité critique non corrigée dans la pile de service de l'IA, mais c'est l'une des plus lourdes de conséquences en raison de l'omniprésence du logiciel. Les moteurs d'inférence open source comme vLLM sont devenus des composants porteurs dans les déploiements LLM de production à travers la région, et leurs chaînes de dépendances — y compris les couches de cache, les tokenizers et l'outillage d'orchestration — évoluent plus vite que les revues de sécurité.
Pour la région du CCG, où les initiatives d'IA souveraine et les déploiements LLM en entreprise s'accélèrent, c'est un rappel que la « sécurité de l'infrastructure IA » n'est plus une préoccupation de niche. Les modèles ne sont que la couche de calcul. La véritable surface d'attaque est tout ce qui les entoure : le cache, l'orchestrateur, le conteneur, le réseau.
Chez Aratech, nous construisons le moteur de contexte et les boucles opérationnelles qui reposent précisément sur ce type d'infrastructure. Nous réfléchissons en termes de ce qui peut être atteint, de qui peut l'atteindre, et de ce qui se passe lorsqu'un message non fiable arrive sur le port 5555 sans les identifiants de quiconque.
C'est l'état d'esprit auquel chaque équipe exécutant de l'inférence LLM à grande échelle devrait réfléchir en ce moment même.