En bref

  • CVE-2026-25874 (CVSS 9.3) : RCE non authentifiée sur LeRobot, plateforme robotique open source de Hugging Face.
  • Cause : désérialisation pickle sur des endpoints gRPC en clair, sans TLS ni authentification.
  • Aucun patch disponible. Fix prévu en version 0.6.0. Versions ≤ 0.5.1 vulnérables.

Les faits

Les chercheurs de Resecurity ont publié le 28 avril 2026 les détails de CVE-2026-25874, une vulnérabilité critique affectant LeRobot, la plateforme open source de robotique et d'apprentissage par imitation maintenue par Hugging Face. La faille porte un score CVSS 9.3 et permet à un attaquant non authentifié, simplement présent sur le réseau de la machine cible, d'exécuter des commandes arbitraires avec les privilèges du processus LeRobot.

L'origine technique est limpide. Les composants PolicyServer et RobotClient de LeRobot utilisent le module pickle natif de Python pour désérialiser des données reçues via des canaux gRPC. Le serveur gRPC est instancié avec add_insecure_port(), c'est-à-dire sans TLS ni authentification. Toute personne capable d'atteindre le port d'écoute peut envoyer une charge utile pickle forgée, qui sera désérialisée et exécutée. Or pickle est notoirement dangereux : la désérialisation de données non fiables permet l'exécution arbitraire via la méthode __reduce__.

Le détail le plus troublant tient à la trace écrite du compromis sécurité. Le chercheur Chocapikk a découvert dans le code source des balises # nosec placées directement à côté des appels pickle.loads(). Ces commentaires sont conçus pour faire taire les linters de sécurité automatisés — typiquement Bandit pour Python — qui auraient correctement signalé l'usage dangereux de pickle. Les développeurs LeRobot ont donc explicitement supprimé l'avertissement plutôt que de corriger le code, ce qui constitue une dette de sécurité documentée.

Cette pratique est d'autant plus déconcertante que Hugging Face est l'organisation à l'origine du format safetensors, conçu spécifiquement pour éliminer les risques associés à la sérialisation pickle dans le partage de modèles ML. Le projet a investi des ressources considérables pour proposer une alternative sûre, qui est aujourd'hui largement adoptée pour les poids de modèles. Mais dans LeRobot, les développeurs ont retenu pickle pour des raisons de commodité d'implémentation, en court-circuitant les garde-fous de revue de code.

L'impact dépasse largement le cadre d'un PoC académique. LeRobot est conçu pour piloter des systèmes d'inférence IA et des robots physiques, qui s'exécutent typiquement avec des privilèges élevés afin d'accéder à des réseaux internes, à des datasets de taille conséquente et à des ressources GPU coûteuses. Un attaquant qui obtient l'exécution sur un nœud d'inférence peut donc se déplacer latéralement, corrompre les modèles d'apprentissage, exfiltrer les clés Hugging Face API stockées localement, ou pire, sabotter les commandes physiques envoyées aux robots connectés.

Le scénario d'attaque sur un robot industriel est concret. Imaginez un bras robotique piloté par un PolicyServer LeRobot dans une usine ou un laboratoire. Un attaquant ayant gagné l'accès au réseau interne — par phishing, VPN compromis, ou via un autre vecteur — peut envoyer une charge pickle forgée qui modifie les paramètres de contrôle du robot ou injecte des commandes physiques arbitraires. Dans les contextes médicaux ou industriels où la robotique est utilisée, les conséquences sortent du périmètre purement informatique.

Le statut du correctif est insatisfaisant à la date de publication. Aucun patch n'est disponible pour les versions actuelles. Le fix est annoncé pour la version 0.6.0, sans calendrier précis. Toutes les versions ≤ 0.5.1 sont vulnérables. Hugging Face n'a pas publié de mitigation officielle, ce qui laisse les utilisateurs gérer eux-mêmes l'exposition. Resecurity recommande à minima de placer les services LeRobot derrière un firewall strict, voire de les isoler complètement du réseau jusqu'à publication d'un correctif.

Impact et exposition

L'exposition réelle est conditionnée à l'accessibilité réseau du PolicyServer. Les déploiements de laboratoire ou de production qui exposent le port gRPC sur un réseau interne large constituent les premières cibles. Les recherches sur Shodan permettent d'identifier des instances LeRobot accessibles depuis Internet, bien que la plupart des déploiements soient confinés à des réseaux internes ou des VPN.

Le périmètre concerné inclut tout chercheur, startup robotique ou intégrateur industriel utilisant LeRobot pour l'apprentissage par démonstration ou l'inférence en production. Les écosystèmes académiques sont particulièrement exposés, car les bonnes pratiques de segmentation réseau y sont moins systématiquement appliquées qu'en environnement entreprise.

Recommandations

  • Identifier toutes les instances LeRobot ≤ 0.5.1 dans l'environnement et placer leurs ports gRPC derrière un firewall strict avec liste blanche d'IP.
  • Ne jamais exposer un serveur LeRobot à Internet ou à un réseau partagé multi-tenant.
  • Surveiller le repo GitHub de LeRobot pour la sortie de la version 0.6.0 et planifier la migration en priorité critique.
  • Auditer le réseau pour détecter des connexions gRPC sortantes anormales depuis les machines hébergeant des PolicyServer.
  • Pour les contextes industriels : isoler physiquement le contrôle robotique du réseau IT général.

Alerte critique

Aucun patch disponible. Tout PolicyServer LeRobot accessible sur le réseau doit être considéré comme un point d'entrée RCE pour quiconque peut atteindre son port gRPC. Les déploiements robotiques en production doivent être isolés en attendant la version 0.6.0.

Pourquoi pickle reste-t-il utilisé dans des projets de cette envergure ?

pickle est natif à Python, supporte la sérialisation arbitraire d'objets et reste extrêmement commode pour prototyper. Dans LeRobot, les développeurs avaient besoin de transporter des structures Python complexes (tenseurs, configurations, états de policy) entre processus, et pickle offrait la solution la plus rapide. Le choix s'est fait au détriment de la sécurité, malgré la disponibilité de safetensors et de protocoles plus sûrs comme Protobuf ou MessagePack avec validation de schéma.

Que faire si je ne peux pas isoler immédiatement mon serveur LeRobot ?

À défaut d'isolation réseau complète, mettre en place une règle iptables ou un firewall applicatif acceptant uniquement les IP des clients connus. Surveiller activement les logs du PolicyServer pour détecter des connexions inattendues. Réduire les privilèges du compte exécutant le service au strict minimum (pas de root, pas d'accès aux secrets cloud). En dernier recours, désactiver complètement le service jusqu'à publication du fix 0.6.0.

Votre infrastructure IA est-elle exposée ?

Ayi NEDJIMI realise des audits de securite cibles sur les infrastructures IA et robotiques pour identifier vos vulnerabilites avant qu'elles ne soient exploitees.

Demander un audit