El robot humanoide Unitree G1 EDU, estrella de los laboratorios de investigación, puede ser comprometido y activado de forma remota mediante dos vulnerabilidades críticas, una de las cuales ni siquiera requiere estar en la misma red, solo estar a alcance Bluetooth.

Piratear un robot humanoide vía Bluetooth: las fallas del Unitree G1 EDU abren una nueva era de seguridad física

Qué está pasando

El Unitree G1 EDU es uno de los robots humanoides más accesibles del mercado: 35 kg de mecánica de precisión, dos piernas, dos brazos, sensores por todas partes, vendido como plataforma de investigación abierta. Se encuentra en decenas de laboratorios universitarios y centros de I+D en todo el mundo.

Se acaban de revelar dos fallas en su arquitectura. La primera: una vulnerabilidad que permite obtener permisos root mediante RCE —control total del sistema operativo, de los actuadores y de los sensores—. La segunda: una activación de Bluetooth sin autenticación —a alcance de Bluetooth del robot, cualquiera puede desencadenar acciones del sistema. Sin contraseña, sin emparejamiento, nada.

Por qué estas fallas son únicas

Las RCE las vemos cada semana. La activación no autenticada vía Bluetooth en un robot físico de 35 kg es diferente: el riesgo ya no es solo informático, se vuelve físico.

Un robot humanoide comprometido en un laboratorio podría ser controlado a distancia para moverse, agarrar objetos o simplemente caer —con las consecuencias físicas que eso implica—. No es ciencia ficción: es el riesgo directo e inmediato de estas vulnerabilidades en contextos reales de uso.

Los escenarios de riesgo concreto incluyen laboratorios universitarios de acceso semiabierto, demostraciones públicas en ferias y exposiciones tecnológicas, y hackerspaces o fab labs donde el acceso físico es difícil de controlar.

La seguridad en robótica, un desafío enorme y urgente

Estas dos fallas ilustran un retraso estructural: la seguridad de los sistemas robóticos está donde estaba la seguridad informática hace 20 años. Los fabricantes optimizan para el rendimiento, la facilidad de desarrollo y la estabilidad. La seguridad queda al final de la lista.

La falla de Bluetooth es especialmente reveladora: la industria móvil resolvió los problemas de autenticación Bluetooth entre los años 2000 y 2010. Verlos reaparecer en 2026 en robótica muestra que cada nuevo campo tecnológico debe reaprender las lecciones de seguridad de la manera más dura.

A medida que los robots humanoides abandonan los laboratorios para entrar en almacenes, hospitales y espacios públicos, estas fallas dejarán de ser académicas. La era de la seguridad robótica comienza ahora —con retraso, como siempre.

Qué hacer ahora

Acciones inmediatas

1. Revise los boletines de seguridad de Unitree para buscar un firmware correctivo —aplíquelo de inmediato si está disponible.
2. Desactive Bluetooth si no se usa: en Linux embebido, rfkill block bluetooth —evaluar según las necesidades experimentales.
3. Controle el acceso físico: hasta que se aplique el parche, el robot debe estar en un espacio de acceso estrictamente controlado.
4. Aísle el robot en una red dedicada: sin conexión a los recursos sensibles del laboratorio desde el G1 EDU.
5. Informe a su responsable de seguridad si su institución posee unidades G1 EDU —es un riesgo físico documentado, no una hipótesis.