Dans la course à l’accélération de l’adoption de l’IA, les entreprises s’appuient de plus en plus sur des serveurs d’inférence haute performance pour déployer des modèles à grande échelle.
Pourtant, le rythme effréné du développement a mis au jour un angle mort critique : les infrastructures fondamentales de l’IA reposent souvent sur du code réutilisé, hérité et insuffisamment audité.
Les chercheurs en sécurité d’Oligo Security ont révélé que des vulnérabilités d’exécution de code à distance (RCE) s’étaient propagées dans plusieurs frameworks d’IA majeurs selon un schéma que l’équipe appelle ShadowMQ — une faille dissimulée de la couche de communication, enracinée dans l’utilisation non sécurisée de ZeroMQ (ZMQ) et dans les pratiques de désérialisation de Python pickle.
Ce problème touche un large éventail de projets leaders du secteur, notamment Llama Stack de Meta, NVIDIA TensorRT-LLM, Sarathi-Serve de Microsoft, vLLM, SGLang et Modular Max, créant des risques de sécurité communs et généralisés dans tout l’écosystème de l’IA.
- La découverte de ShadowMQ
- Les risques cachés de la réutilisation du code d’IA
- Pourquoi les serveurs d’inférence sont des cibles privilégiées
- Comment les fournisseurs ont réagi à ShadowMQ
- Pourquoi le code non sécurisé se répète dans les projets d’IA
- Principales mesures pour sécuriser les infrastructures d’IA
- Les vulnérabilités héritées dans la pile d’IA
La découverte de ShadowMQ
L’enquête a débuté en 2024, lorsque les chercheurs d’Oligo ont identifié un schéma dangereux au sein de Llama Stack de Meta : le framework utilisait la méthode recv_pyobj(), qui désérialise automatiquement les données à l’aide du module pickle de Python.
Comme pickle peut exécuter du code arbitraire pendant la désérialisation, son utilisation sur des sockets réseau non authentifiés crée une voie directe vers l’exécution de code à distance.
Meta a réagi rapidement en publiant CVE-2024-50050 et en remplaçant pickle par une méthode de sérialisation basée sur JSON.
L’équipe de recherche a rapidement découvert des problèmes similaires ailleurs. NVIDIA TensorRT-LLM, vLLM, SGLang et Modular Max réutilisaient tous le même code non sécurisé — ou un code presque identique.
Dans certains cas, des fichiers avaient été copiés ligne par ligne d’un projet à l’autre, y compris les commentaires d’en-tête indiquant leur origine.
SGLang précise par exemple explicitement qu’un fichier vulnérable a été « adapté de vLLM », héritant non seulement des optimisations architecturales, mais aussi de la logique de désérialisation défectueuse.
Les risques cachés de la réutilisation du code d’IA
ShadowMQ illustre la manière dont les vulnérabilités se propagent silencieusement dans les pratiques modernes de développement de l’IA.
Les responsables de frameworks empruntent fréquemment des composants à des projets concurrents afin d’optimiser les performances et d’accélérer les mises à jour.
Cette réutilisation n’est pas intrinsèquement nuisible, mais lorsque des méthodes de communication non sécurisées, comme la désérialisation basée sur pickle, sont copiées sans examen de sécurité, des écosystèmes entiers héritent de la même faiblesse.
La nature en cascade de ShadowMQ signifie qu’une seule faille négligée peut se propager à plusieurs fournisseurs, établissements de recherche et opérateurs cloud.
Pourquoi les serveurs d’inférence sont des cibles privilégiées
Les serveurs d’inférence d’IA traitent des invites de modèles sensibles, des jeux de données propriétaires et des entrées client sur des clusters de GPU.
L’exploitation de ShadowMQ pourrait permettre à des attaquants d’exécuter du code arbitraire, d’élever leurs privilèges, de dérober des modèles ou des secrets et d’installer des cryptomineurs exploitant les GPU, comme ceux observés lors de la campagne ShadowRay.
Les analyses d’Oligo ont révélé des milliers de sockets ZMQ exposés, diffusant la bannière TCP caractéristique du protocole sur l’Internet public — certaines appartenant clairement à des environnements d’inférence en production. Un seul appel de désérialisation vulnérable pourrait compromettre des opérations d’IA entières.
Comment les fournisseurs ont réagi à ShadowMQ
Après la divulgation coordonnée, plusieurs grands fournisseurs ont publié rapidement des correctifs :
- Meta Llama Stack (CVE-2024-50050) a remplacé pickle par JSON.
- vLLM (CVE-2025-30165) a corrigé la logique non sécurisée en faisant de son moteur V1 sécurisé la solution par défaut.
- NVIDIA TensorRT-LLM (CVE-2025-23254) a ajouté une validation HMAC, obtenant une note critique de 9,3.
- Modular Max Server (CVE-2025-60455) a adopté msgpack pour une sérialisation sécurisée.
Selon les chercheurs, tous les frameworks n’ont pas été corrigés avec succès. Sarathi-Serve de Microsoft reste vulnérable et les correctifs de SGLang ne sont que partiels. Ces failles persistantes représentent des vulnérabilités fantômes — des problèmes connus des défenseurs, mais laissés sans réponse et qui attendent d’être redécouverts par des acteurs malveillants.
Pourquoi le code non sécurisé se répète dans les projets d’IA
La prévalence de ShadowMQ ne résulte pas de la négligence des développeurs. Elle reflète plutôt les réalités structurelles de l’écosystème de l’IA :
- Les impératifs de performance encouragent la réutilisation du code.
- Les méthodes non sécurisées comme recv_pyobj() ne sont pas accompagnées d’avertissements suffisamment visibles.
- Les outils de génération de code reproduisent fréquemment des schémas courants, mais non sécurisés.
- Les examens de sécurité ne suivent pas le rythme de l’innovation rapide dans l’IA.
Par conséquent, une seule implémentation vulnérable peut se propager discrètement dans des dizaines de dépôts.
Principales mesures pour sécuriser les infrastructures d’IA
Comme les vulnérabilités ShadowMQ découlent à la fois de paramètres par défaut non sécurisés et de code hérité, les entreprises doivent prendre des mesures proactives pour sécuriser leurs infrastructures d’IA.
- Corriger et mettre à jour tous les frameworks d’inférence d’IA vers les dernières versions sécurisées, et auditer en continu le code réutilisé ou hérité afin d’y détecter les schémas dangereux.
- Éliminer la sérialisation non sécurisée en évitant pickle ou /recv_pyobj() pour toute donnée non fiable et en imposant des formats sûrs comme JSON, msgpack ou protobuf.
- Sécuriser toutes les communications ZMQ et interservices en exigeant une authentification (HMAC/TLS), en chiffrant les canaux et en bloquant toute exposition publique grâce à une segmentation stricte du réseau et à des règles de pare-feu.
- Restreindre les accès et renforcer l’infrastructure en évitant tcp://*, en limitant les endpoints ZMQ aux réseaux de confiance, en isolant les serveurs d’inférence grâce au renforcement des conteneurs et en appliquant les principes du zero trust.
- Améliorer la surveillance et la détection grâce à la journalisation, à la détection des anomalies, à une couverture EDR/XDR, à l’analyse des endpoints exposés et à des alertes en cas de désérialisation ou de comportement protocolaire anormal.
- Sensibiliser les équipes de développement et d’ingénierie aux risques liés à la sérialisation, aux pratiques de communication sécurisées et aux dangers de la réutilisation du code, en s’appuyant sur des contrôles ou des politiques CI qui bloquent les schémas dangereux.
En adoptant ces mesures d’atténuation et en renforçant les pratiques de développement, de communication et d’infrastructure sécurisées, les entreprises peuvent développer leur cyberrésilience face aux vulnérabilités de type ShadowMQ.
Les vulnérabilités héritées dans la pile d’IA
ShadowMQ montre que l’infrastructure moderne de l’IA hérite souvent de failles de sécurité au lieu de les créer de toutes pièces.
À mesure que les entreprises intègrent des composants open source à une vitesse sans précédent, les vulnérabilités peuvent se propager silencieusement dans les frameworks, les clouds et les environnements d’entreprise.
Pour atténuer ces risques, il faut traiter la pile d’IA avec la même rigueur que tout autre système critique — auditer le code réutilisé, imposer des schémas de communication plus sûrs et donner la priorité à une sérialisation sécurisée.
Cette dépendance croissante à l’égard d’un code partagé et hérité montre clairement que la sécurisation de l’écosystème de l’IA commence par le renforcement de la chaîne d’approvisionnement logicielle dont dépendent les développeurs.