Unitree G1 EDU : deux failles pourraient donner un accès root à des attaquants proches

La divulgation d’août 2026 baptisée « UniBLEed » décrit deux chaînes d’attaque distinctes visant les firmwares du Unitree G1 EDU jusqu’à la version 1.5.2. La première commence avec un attaquant non authentifié situé dans la portée Bluetooth ; la seconde exploite des services accessibles depuis un réseau adjacent et la fonction chat_go de gestion de base de connaissances. Toutes deux ont été présentées comme pouvant conduire à un accès root sur le Locomotion PC du robot. 158

L’enjeu dépasse donc la compromission d’une application compagnon ou d’une simple session Bluetooth. Le Locomotion PC prend en charge des fonctions sensibles du robot, notamment les moteurs, les caméras, l’audio et les capacités vocales. 513

CVE-2026-76640 : une chaîne BLE jusqu’à root

La faille Bluetooth est la plus inhabituelle des deux : l’attaquant n’a pas besoin de commencer par accéder au réseau local du robot. Les informations publiées décrivent une interaction avec des fonctions GATT exposées, depuis la proximité du robot, sans appairage ni identifiants Unitree. 5813

La chaîne rapportée combine plusieurs faiblesses :

• Un point d’accès cloud de Unitree aurait permis à un compte gratuit de récupérer la clé AES-128 d’un G1 sans vérifier correctement que le compte était bien associé au robot ciblé. 811
• Cette clé pouvait ensuite être utilisée pour atteindre des opérations BLE protégées, injecter une clé prépartagée et déclencher un mécanisme de secours destiné au provisioning Wi-Fi. 811
• Le traitement insuffisamment sûr des données de provisioning — notamment une variable non protégée dans un heredoc — pouvait être combiné à des défauts de la pile de provisioning BLE et Wi-Fi afin d’aboutir à l’exécution de commandes arbitraires avec les privilèges root. 511

Les descriptions publiques de la vulnérabilité mentionnent également un débordement de mémoire dans le traitement du SSID. Celui-ci pouvait corrompre une entrée voisine utilisée pour la distribution de pointeurs de fonction, puis permettre l’appel de données contrôlées par l’attaquant via system() avec les privilèges root. 35

Pourquoi la proximité physique change la donne

L’attaquant doit être suffisamment proche pour communiquer en Bluetooth, mais il n’aurait pas nécessairement besoin d’un compte, d’un mot de passe ou d’un appairage préalable. Le profil de risque est donc différent pour les robots utilisés lors de démonstrations publiques, dans des laboratoires, des entrepôts ou des espaces partagés.

Les chercheurs ont aussi évoqué un scénario de propagation de type ver informatique : un G1 compromis pourrait, en théorie, rechercher puis cibler d’autres G1 vulnérables à proximité. Il s’agit d’une capacité potentielle de la chaîne d’attaque, et non de la preuve qu’un ver a été déployé dans la nature. 58

Cette inquiétude s’inscrit dans un contexte plus large. Des firmwares Unitree apparentés avaient déjà été associés à une injection de commandes via des données Wi-Fi malveillantes traitées après une interaction de provisioning BLE.

CVE-2026-76639 : une autre voie via chat_go

La CVE-2026-76639 exploite un point d’entrée différent. Selon la NVD, les firmwares du G1 EDU jusqu’à la version 1.5.2 sont vulnérables à une chaîne non authentifiée d’exécution de code avec les privilèges root, accessible depuis un réseau adjacent. Cette chaîne combine trois faiblesses : un pont WebRTC-DDS exposé sur le port TCP 9991, une clé AES-128 statique conservée avec des permissions trop permissives et une traversée de répertoires dans l’API de téléversement de connaissances chat_go. 1

À haut niveau, la traversée de répertoires pouvait permettre de déposer un fichier malveillant dans un répertoire autorisé par bashrunner. Le service pouvait alors l’exécuter avec les privilèges root, transformant une faille de placement de fichier en exécution de code. 14

Cette voie ne dépend pas de la présence physique de l’attaquant à proximité du robot en Bluetooth. Son exposition pratique dépend plutôt de l’accessibilité des services réseau concernés et de la possibilité, pour des appareils non fiables, de communiquer avec eux.

Quelles fonctions seraient exposées ?

Un accès root au Locomotion PC pourrait donner le contrôle de logiciels reliés aux fonctions essentielles du robot. Les informations publiées citent notamment la locomotion et les moteurs, les caméras, les microphones, la lecture audio et les fonctions vocales. 513

Les conséquences sont à la fois informatiques et physiques : surveillance potentielle, activation audio non autorisée, perturbation du service ou mouvements dangereux. Les éléments disponibles établissent la sensibilité des systèmes concernés, mais ne prouvent pas qu’un G1 particulier a été exploité ni qu’un incident dangereux s’est produit dans le monde réel.

Réponse de Unitree : des correctifs, mais une version précise encore incertaine

Les informations publiques indiquent que Unitree a validé les signalements et publié des correctifs. 6 D’autres articles mentionnent l’ajout, en juillet 2026, d’un contrôle associant le compte au robot réellement détenu. 12

Cependant, les éléments disponibles ne fournissent pas d’avis de sécurité du fabricant reliant chaque CVE à une version corrective précise du firmware G1 EDU. La plage documentée comme affectée couvre les firmwares jusqu’à la version 1.5.2. 15 Aucune version corrigeant de manière vérifiable tous les éléments des deux chaînes n’a pu être confirmée dans les recommandations accessibles. 8

Les exploitants ne devraient donc pas supposer qu’une mise à jour simplement présentée comme « la dernière disponible » règle nécessairement les deux vulnérabilités. Il faut vérifier la version installée et obtenir une confirmation directe de Unitree.

Mesures recommandées aux opérateurs

1. Confirmer le correctif auprès de Unitree. Demandez la ou les versions exactes corrigeant les CVE-2026-76639 et CVE-2026-76640, puis vérifiez la version installée sur chaque robot.
2. Réduire l’exposition physique. Tant que la correction n’est pas confirmée, éloignez les robots concernés des personnes non fiables et des autres G1 vulnérables. Désactivez aussi le provisioning BLE lorsque cela est compatible avec l’exploitation du robot.
3. Segmenter le réseau. Placez les systèmes G1 sur des réseaux isolés et soumis à des contrôles d’accès. Bloquez les connexions entrantes inutiles vers les services d’administration, WebRTC/DDS et provisioning.
4. Limiter les téléversements. Désactivez ou restreignez les téléversements de bases de connaissances chat_go lorsque c’est possible. Examinez également les répertoires autorisés par bashrunner, ainsi que les fichiers de service, à la recherche de modifications inattendues.
5. Enquêter en cas de suspicion. Considérez toute compromission inexpliquée comme un incident potentiel au niveau root : renouvelez les identifiants et les clés concernés, examinez les journaux et les changements du système de fichiers, puis réinstallez le robot depuis une source Unitree fiable si nécessaire.

La principale leçon d’UniBLEed est que la sécurité d’un robot dépend de toute sa chaîne de contrôle connectée. Une interface BLE, une vérification d’autorisation dans le cloud, un script de provisioning ou une fonction de téléversement liée à l’IA peut devenir un chemin vers le système qui commande la machine physique lorsque les frontières d’authentification et les privilèges d’exécution ne sont pas appliqués de manière cohérente.