Faille critique non corrigée dans LMCache permettant l'exécution de code à distance

Des chercheurs en sécurité ont identifié une vulnérabilité critique dans LMCache, une couche d'accélération open source pour les serveurs de grands modèles de langage comme vLLM. Divulguée le 7 octobre par JFrog, cette faille permet à des attaquants non authentifiés d'exécuter du code arbitraire sur les systèmes affectés. À la date de rédaction de cet article, aucune version logicielle corrigée n'est disponible, laissant les opérateurs dépendants de modifications de configuration réseau pour se protéger.

Ce qui s'est passé

La vulnérabilité, référencée sous CVE-2026-105192, présente un score de gravité de 9,8 sur 10. Elle affecte les versions de LMCache depuis la 0.3.9, publiée en octobre 2025, jusqu'à la dernière version stable 0.5.5. Le problème persiste également dans les candidats de publication (release candidates) de la version 0.5.6 et dans la branche de développement actuelle. L'équipe de recherche en sécurité de JFrog, dirigée par Yuval Moravchick, a découvert qu'un seul message réseau élaboré peut déclencher l'exécution de code à distance sur le serveur de cache.

Le niveau de risque dépend fortement de la configuration du déploiement. Par défaut, le serveur multiprocessus de LMCache écoute uniquement sur la machine locale, ce qui empêche l'accès externe. Cependant, de nombreux déploiements multi-nœuds nécessitent que le serveur écoute sur une adresse routable afin de partager les données mises en cache entre les machines. La configuration Kubernetes d'exemple fournie par LMCache configure elle-même le serveur pour écouter sur toutes les interfaces réseau, l'exposant ainsi effectivement au réseau du cluster. Dans ces configurations, tout hôte pouvant atteindre le port peut exploiter la faille.

Aggravant la gravité de la situation, les images de conteneurs officielles de LMCache exécutent le processus avec les privilèges root. Cela signifie qu'une exploitation réussie accorde à l'attaquant des privilèges administratifs complets sur l'hôte. JFrog note que si les pare-feu peuvent limiter l'exposition, ils n'éliminent pas totalement le risque si un hôte de confiance situé dans la plage autorisée est compromis. Il n'existe actuellement aucun moyen fourni pour déterminer si un serveur a déjà été attaqué.

Comment cela fonctionne

La cause profonde réside dans la manière dont LMCache gère la communication inter-processus via la bibliothèque de messagerie ZeroMQ. Le serveur multiprocessus ouvre un socket pour que les processus travailleurs s'enregistrent et partagent les données mises en cache, mais ce socket ne dispose d'aucun mécanisme d'authentification. Lorsqu'un message arrive, le serveur utilise le module pickle de Python pour désérialiser les données. Pickle est connu pour être dangereux avec des données non fiables car il peut exécuter du code arbitraire lors du processus de décodage.

De manière cruciale, le serveur dépaquette les données pickle tout en lisant les arguments du message, avant même de vérifier le type de message. Cet ordre d'opérations permet à un attaquant d'envoyer une charge utile malveillante qui s'exécute immédiatement à la réception. Le code s'exécute avec les mêmes privilèges que le processus LMCache, qui, comme noté précédemment, est souvent root dans les environnements conteneurisés. Ce modèle fait écho à un groupe de failles appelées ShadowMQ, identifiées dans d'autres frameworks d'inférence IA en novembre 2025, bien qu'un lien direct avec le code n'ait pas été établi.

Détails clés

• Identifiant CVE : CVE-2026-105192, évalué à 9,8/10 en termes de gravité.
• Versions affectées : LMCache 0.3.9 à 0.5.5, ainsi que les candidats de publication 0.5.6 et les branches de développement.
• Vecteur d'attaque : Message réseau non authentifié via un socket ZeroMQ en mode multiprocessus.
• Cause racine : Désérialisation non sécurisée utilisant Python pickle avant la validation du type de message.
• Niveau de privilège : Le code s'exécute en tant qu'utilisateur LMProcess, qui est root dans les conteneurs officiels.
• Statut du correctif : Aucune version corrigée n'est actuellement disponible.

Pourquoi c'est important

Pour les équipes d'ingénierie construisant des infrastructures IA, cette vulnérabilité met en lumière les risques liés à l'adoption de nouveaux outils d'accélération sans audit de sécurité rigoureux. LMCache est conçu pour accélérer l'inférence des LLM, une métrique de performance critique pour les applications de production. Cependant, les exemples par défaut fournis par le projet encouragent des liaisons réseau non sécurisées. Les opérateurs qui suivent ces exemples pour configurer des clusters multi-nœuds exposent involontairement leurs systèmes à l'exécution de code à distance.

L'absence de correctif force les équipes à choisir entre performance et sécurité. Désactiver l'adresse routable casse la mise en cache multi-nœuds, dégradant potentiellement la qualité de service. La laisser ouverte laisse la porte grande ouverte aux attaquants. Cette situation souligne l'importance des stratégies de défense en profondeur, telles que la segmentation réseau stricte et les principes de moindre privilège, plutôt que de compter uniquement sur la sécurité au niveau de l'application.

De plus, la découverte de six autres rapports de sécurité non confirmés sur GitHub suggère des problèmes plus larges d'hygiène au sein du projet. Bien que ceux-ci manquent de références CVE ou de confirmation des mainteneurs, ils pointent vers des accès non authentifiés potentiels aux données des locataires et à d'autres services. Les équipes utilisant LMCache doivent désormais surveiller non seulement cette CVE spécifique, mais aussi la posture globale de sécurité du projet et sa réponse aux menaces émergentes.

Que pouvez-vous faire

• Restreindre l'accès réseau : Configurez le serveur multiprocessus de LMCache pour qu'il écoute uniquement sur localhost ou sur un réseau de cluster isolé et fiable.
• Éviter la liaison publique : Ne liez pas le serveur à des adresses routables accessibles depuis des réseaux non fiables ou Internet public.
• Implémenter des pare-feu : Utilisez des règles de pare-feu pour limiter strictement les adresses IP pouvant se connecter au port LMCache, bien que cela n'atténue pas complètement le risque.
• Vérifier les privilèges des conteneurs : Si possible, modifiez les configurations des conteneurs pour exécuter le processus LMCache en tant qu'utilisateur non-root afin de limiter l'impact d'une exploitation.
• Surveiller les mises à jour : Suivez attentivement le dépôt LMCache et les communications de JFrog concernant les correctifs disponibles.