Investigador revela dos vectores que permiten root remoto en Unitree G1 EDU

Un investigador de seguridad ha revelado dos cadenas independientes que permiten ejecución remota de código con privilegios de root en el robot Unitree G1 EDU. Según la divulgación técnica publicada el 27 de agosto de 2026 por Olivier Laflamme, las rutas de compromiso son distintas: una explota una condición de path traversal en componentes de red para alcanzar un ejecutor local llamado bashrunner, y la otra parte de una interacción Bluetooth Low Energy (BLE) que, combinada con una autorización deficiente en el servicio en la nube, permite llegar a una vulnerabilidad de provisión Wi‑Fi que deriva en ejecución root en el ordenador de locomoción del robot.

Hechos confirmados: Laflamme ha asignado números CVE a ambas fallas (CVE‑2026‑76639 y CVE‑2026‑76640) y documentó técnicamente cómo cada cadena culmina en root sobre el llamado Locomotion PC —el sistema integrado que controla motores y actuadores del G1 EDU—. En la ruta por red (CVE‑2026‑76639) la explotación comienza con un path traversal en un servicio identificado como chat_go que permite escribir en la lógica de bashrunner, cuyo abuso desemboca en ejecución con privilegios de root. En la ruta BLE (CVE‑2026‑76640) el atacante puede escribir un vector de arranque sin emparejamiento Bluetooth; esa fase inicial por sí sola no da control, pero, según Laflamme, una comprobación de propiedad defectuosa en el servicio cloud permitió recuperar material de claves para un robot distinto, lo que a su vez habilitó el estado BLE autenticado necesario para alcanzar el código de provisión Wi‑Fi, donde existe un desbordamiento que permite elevar a root.

Qué está confirmado y qué no: está confirmado que Laflamme realizó pruebas controladas con dos G1 en la misma sala y que limitó la propagación del exploit a ese entorno de laboratorio. También ha dicho que Unitree aplicó en julio de 2026 un arreglo al chequeo de vinculación entre cuenta cloud y robot; según él, esa corrección rompe el flujo exacto que usó para su prueba de concepto. No está confirmado por Unitree (al menos públicamente y según la información disponible) qué versiones de firmware distribuidas son las que corrigen completamente ambos CVE, ni si otros modelos de Unitree más allá del G1 EDU comparten los mismos componentes vulnerables.

Es relevante notar otra precisión técnica aportada por Laflamme: su robot de pruebas fue actualizado a V1.5.2 durante el trabajo, pero esa secuencia no establece por sí misma que la versión V1.5.1.1 esté afectada. En otras palabras, hay confirmación del problema en el laboratorio y del vector de explotación, pero el mapa exacto de versiones afectadas en instalaciones reales aún carece de una declaración pública del fabricante verificable por terceros.

Cómo funcionan los ataques, en términos técnicos: la primera cadena se basa en abuso de rutas de archivo (path traversal) en una interfaz de red que permite a un atacante introducir comandos en un componente que invoca bashrunner; ese ejecutor no realiza controles suficientes de contexto ni de privilegios, y termina ejecutando código con permisos de root en el subsistema de locomoción. La segunda cadena combina una operación BLE inicial que no exige emparejamiento —aceptando un mensaje bootstrap protegido en sí— con una falla de autorización en la nube que permitió recuperar claves asociadas a otro dispositivo. Con esas claves el atacante obtiene el estado BLE autenticado necesario para ejecutar la rutina de provisión Wi‑Fi, donde existe un desbordamiento de buffer explotable que de nuevo culmina con root en el ordenador de locomoción.

Quiénes resultan afectados y por qué importa: propietarios operativos del Unitree G1 EDU son el grupo directamente en riesgo —esto incluye laboratorios de investigación, universidades, empresas que usen estos robots para educación o demostraciones— porque un atacante con acceso de red local o con proximidad física Bluetooth podría lograr control total de los motores y sensores del robot. La capacidad de ejecutar código como root sobre la plataforma de locomoción implica control físico (movimiento de patas, cámaras, micrófonos), pérdida de integridad de datos, posibilidad de instalar persistencia local y riesgo de comprometer credenciales que permitan acceso a otros robots o servicios asociados. Además, la recuperación de claves mediante el cloud abre el vector de ataque desde cuentas remotas si la autorización no está adecuadamente restringida.

Consecuencias reales y riesgos prácticos: más allá del perjuicio informático, la explotación puede traducirse en daños físicos —colisiones, movimientos inesperados, riesgo para personal— y en pérdida de propiedad intelectual o de datos capturados por el robot. Si la cadena pudiera replicarse a más de dos unidades en masa mediante claves recuperadas o propagación en redes locales, el impacto sería mayor; por ahora esa amplitud de propagación no ha sido demostrada públicamente.

Las implicaciones para organizaciones que integren estos robots en sus operaciones incluyen necesidad de revaluar controles de acceso físico y lógicos, revisar segmentación de red (aislar robots en VLANs), y ajustar procesos de provisión y autenticación para evitar que una cuenta cloud comprometa material de clave de dispositivos ajenos.

Medidas concretas y urgentes que deben tomar los operadores del G1 EDU: 1) Aísle inmediatamente los robots G1 EDU de redes no confiables y, si es posible, desconéctelos temporalmente de Wi‑Fi y cloud hasta que Unitree confirme una versión parcheada. 2) Desactive Bluetooth o limite su alcance físico; si no puede, ubique el robot en un espacio controlado donde no haya acceso público cercano. 3) Cambie las credenciales de las cuentas cloud relacionadas, active autenticación multifactor y revise registros de recuperación de claves. 4) Solicite al fabricante la versión exacta de firmware que corrige ambas CVE y exija comprobantes de integridad de la imagen (firmas digitales). 5) Si dispone de capacidades de seguridad, capture imágenes forenses y registros del robot antes de aplicar actualizaciones (para preservar evidencia en caso de incidente). 6) Segmente la red: coloque robots en subredes con reglas de firewall estrictas, limitando salidas y accesos administrativos. 7) Mantenga procedimientos de control de acceso físico que impidan a terceros acercarse lo suficiente para explotar BLE.

Para administradores de mayor escala o responsables de seguridad corporativa, además de las acciones anteriores es aconsejable notificar al CSIRT/CERT interno, coordinar con Unitree para recibir indicaciones formales y, si procede, involucrar a autoridades de respuesta a incidentes. También conviene auditar otros modelos de Unitree desplegados en la organización por si comparten componentes vulnerables.

Fuentes y referencia práctica: Unitree mantiene información de producto y soporte en su sitio oficial https://www.unitree.com/. Para comprender las particularidades y limitaciones del emparejamiento BLE y su seguridad, la especificación oficial de Bluetooth ofrece contexto técnico útil https://www.bluetooth.com/learn-about-bluetooth/core-specification/. Y para guías operativas sobre protección de dispositivos conectados y buenas prácticas de seguridad IoT, la Agencia de Ciberseguridad e Infraestructura de EE. UU. publica recomendaciones prácticas que pueden adaptarse al entorno de robots educativos https://www.cisa.gov/stopthinkconnect/secure-your-devices.

Finalmente, es importante subrayar la incertidumbre que aún existe: la lista pública de versiones firmadas y parcheadas no ha sido verificada por terceros, y Unitree aún no ha comunicado públicamente un número de firmware concreto que corrija ambos CVE en todos los casos. Los operadores deben seguir las comunicaciones oficiales del fabricante y aplicar parches solo desde fuentes verificadas; mientras tanto, las medidas de contención descritas reducen riesgo y evitan posibles daños físicos o compromisos posteriores.