robotica.esrobotica.es
Humanoides

Dos fallos permiten tomar el control root del Unitree G1 EDU

Dos vulnerabilidades del Unitree G1 EDU permiten ejecutar código como root desde una red cercana o Bluetooth; falta una versión pública de firmware corregida.

·
5 min de lectura
Dos fallos permiten tomar el control root del Unitree G1 EDU

Dos vulnerabilidades en el Unitree G1 EDU permiten ejecutar código con privilegios de administrador en el ordenador que controla el movimiento del humanoide. Una de las cadenas parte de la red local del robot; la otra comienza con una conexión Bluetooth sin emparejar y llegó a propagarse entre dos unidades durante una prueba controlada.

Dos caminos distintos hasta el control root

El investigador Olivier Laflamme publicó el 27 de agosto el análisis técnico de CVE-2026-76639 y CVE-2026-76640, dos fallos independientes que reprodujo en cuatro G1. Los registros de vulnerabilidades limitan por ahora el alcance confirmado al modelo G1 EDU y al firmware hasta la versión 1.5.2. Que otros robots de Unitree compartan partes del software no demuestra que estas cadenas funcionen también en ellos.

La primera vulnerabilidad, CVE-2026-76639, recibe una puntuación CVSS de 8,7 sobre 10. Según el aviso publicado en la base de GitHub, un atacante situado en una red adyacente puede encadenar tres debilidades: un puente entre WebRTC y DDS sin autenticación suficiente, una clave AES almacenada con permisos demasiado abiertos y un fallo de recorrido de rutas en el servicio chat_go.

Esa combinación permite colocar un archivo malicioso en un directorio desde el que bashrunner ejecuta scripts. El resultado es una orden lanzada como root en el Locomotion PC, el ordenador que Unitree reserva para las funciones de operación y control del robot. No se trata, por tanto, de acceder únicamente a la aplicación móvil o a una función de entretenimiento.

La segunda cadena, CVE-2026-76640, tiene una puntuación CVSS de 7,7 y empieza más cerca del hardware. El servidor Bluetooth Low Energy aceptaba ciertas escrituras sin emparejamiento previo. El ataque combinaba esa entrada con el proceso de configuración Wi-Fi, un desbordamiento de búfer y una debilidad que entonces permitía recuperar desde la nube material criptográfico de un robot sin comprobar que la cuenta solicitante fuese su propietaria.

La prueba de propagación tiene un límite importante

Laflamme describe UniBLEed como una cadena capaz de propagarse: un G1 comprometido podía buscar otra unidad dentro del alcance Bluetooth y repetir el ataque. El investigador probó ese salto con dos robots en una misma habitación, no con una flota industrial ni a través de internet. La demostración confirma el riesgo dentro de un entorno próximo, pero no permite afirmar que exista una infección activa o que cualquier G1 conectado sea accesible de forma remota.

Además, Unitree añadió entre julio y principios de agosto una comprobación de propiedad en su servicio en la nube. Ese cambio impide que una cuenta cualquiera recupere la clave de otro robot y rompe la prueba de concepto exacta utilizada para la propagación. El propio autor reconoce que la compañía respondió con rapidez, validó los fallos y preparó correcciones para la mayoría o la totalidad de los problemas que notificó.

La incertidumbre está en la distribución de esas correcciones. En el momento de la divulgación, ni la base de avisos ni la cobertura técnica habían podido verificar una versión pública de firmware que solucionase de forma completa ambas CVE. La reparación del servicio en la nube reduce una parte esencial de la segunda cadena, pero no demuestra por sí sola que hayan desaparecido el fallo de Bluetooth, el desbordamiento o el camino separado a través de chat_go.

Un robot físico amplía el impacto de un fallo de software

El G1 EDU es la variante orientada a desarrollo secundario del humanoide compacto de Unitree. La ficha oficial del G1 separa la edición estándar de la EDU, ofrece entre 23 y 43 motores articulares según la configuración y anuncia unas dos horas de batería. La máquina integra conectividad Wi-Fi y Bluetooth, percepción y ordenadores dedicados a desarrollo y locomoción.

Esa arquitectura explica por qué el acceso root importa más que en un dispositivo convencional. Un intruso podría alterar software, extraer secretos o interrumpir servicios internos; cualquier traducción de ese acceso a movimiento físico dependería de los controles, estados y protecciones del robot. La investigación demuestra dominio del ordenador de locomoción, pero no documenta daños a personas ni una toma de control ocurrida fuera del laboratorio.

Para laboratorios y centros educativos, el dato práctico es que no basta con haber actualizado la aplicación móvil. Hasta que Unitree identifique con claridad las versiones corregidas, conviene verificar el firmware directamente con el fabricante, segmentar la red del robot, limitar dispositivos próximos y evitar exponer sus servicios a redes no confiables. Son medidas de contención razonables, no un sustituto de un parche confirmado.

El episodio muestra una tensión cada vez más visible en la robótica comercial: cámaras, micrófonos, Bluetooth, nube, aplicaciones móviles, DDS y ordenadores Linux convierten al robot en un sistema distribuido. La seguridad ya no puede añadirse después de resolver la mecánica. En una máquina que se mueve junto a personas, conocer qué componente está actualizado y qué privilegios conserva cada servicio forma parte de la seguridad funcional del producto.

Fuentes

Más artículos