Investigador revela dois vetores que permitem root remoto em Unitree G1 EDU

Um pesquisador de segurança revelou duas cadeias independentes que permitem execução remota de código com privilégios de root no robô Unitree G1 EDU. Segundo a divulgação técnica publicada em 27 de agosto de 2026 por Olivier Laflamme, as rotas de compromisso são distintas: uma explora uma condição de path traversal em componentes de rede para alcançar um executor local chamadobashrunner, e a outra parte de uma interação Bluetooth Low Energy (BLE) que, combinada com uma autorização deficiente no serviço na nuvem, permite chegar a uma vulnerabilidade de provisão Wi-Fi que deriva em execução root no computador de locomoção do robô.

Atos confirmados: Laflamme atribuiu números CVE a ambas as falhas (CVE‐2026‐76639 e CVE‐2026-76640) e documentou tecnicamente como cada cadeia culmina em root sobre o chamado Locomotion PC — o sistema integrado que controla motores e atuadores do G1 EDU—. Na rota por rede (CVE‐2026‐76639), a exploração começa com um path traversal num serviço identificado comochat_goque permite escrever na lógica debashrunner, cujo abuso resulta em execução com privilégios de root. Na rota BLE (CVE‐2026‐76640) o atacante pode escrever um vetor de arranque sem correspondência Bluetooth; essa fase inicial por si só não dá controle, mas, segundo Laflamme, uma verificação de propriedade defeituosa no serviço cloud permitiu recuperar material de chaves para um robô diferente, o que por sua vez habilitou o estado BLE autenticado necessário para alcançar o código de provisão Wi-Fi, onde existe um excesso que permite elevar ao root.

O que está confirmado e o que não: É confirmado que Laflamme realizou testes controlados com dois G1 na mesma sala e que limitou a propagação do exploit a esse ambiente de laboratório. Também disse que Unitree aplicou em julho de 2026 um arranjo ao cheque de conexão entre conta nuvem e robô; segundo ele, essa correção quebra o fluxo exato que usou para seu teste de conceito. Não é confirmado pela Unitree (pelo menos publicamente e de acordo com as informações disponíveis) quais versões de firmware distribuídas são as que corrigem completamente ambos o CVE, nem se outros modelos de Unitree para além do G1 EDU partilham os mesmos componentes vulneráveis.

É relevante notar outra precisão técnica fornecida por Laflamme: seu robô de testes foi atualizado a V1.5.2 durante o trabalho, mas essa sequência não estabelece por si mesma que a versão V1.5.1.1 esteja afetada. Em outras palavras, há confirmação do problema no laboratório e no vetor de exploração, mas o mapa exato de versões afetadas em instalações reais ainda não possui uma declaração pública do fabricante verificável por terceiros.

Como funcionam os ataques, em termos técnicos: a primeira cadeia baseia-se em abuso de rotas de arquivo (path traversal) numa interface de rede que permite a um atacante introduzir comandos num componente que invocabashrunner; esse executor não realiza controles suficientes de contexto ou de privilégios, e termina executando código com permissões de root no subsistema de locomoção. A segunda cadeia combina uma operação BLE inicial que não exige emparelhamento - aceitando uma mensagem bootstrap protegida em si - com uma falha de autorização na nuvem que permitiu recuperar chaves associadas a outro dispositivo. Com essas chaves o atacante obtém o estado BLE autenticado necessário para executar a rotina de provisão Wi-Fi, onde existe um transbordamento de buffer explorável que de novo culmina com root no computador de locomoção.

Quem é afectado e porque importa: proprietários operacionais do Unitree G1 EDU são o grupo diretamente em risco - isto inclui laboratórios de pesquisa, universidades, empresas que usam esses robôs para educação ou demonstrações - porque um atacante com acesso de rede local ou com proximidade física Bluetooth poderia conseguir controle total dos motores e sensores do robô. A capacidade de executar código como root sobre a plataforma de locomoção implica controle físico (movimento de patas, câmaras, microfones), perda de integridade de dados, possibilidade de instalar persistência local e risco de comprometer credenciais que permitam acesso a outros robôs ou serviços associados. Além disso, a recuperação de chaves através da nuvem abre o vetor de ataque de contas remotas se a autorização não estiver adequadamente restrita.

Consequências reais e riscos práticos: Para além do prejuízo informático, a exploração pode traduzir-se em danos físicos — colisões, movimentos inesperados, risco para pessoal — e perda de propriedade intelectual ou de dados capturados pelo robô. Se a cadeia pudesse ser replicada a mais de duas unidades em massa através de chaves recuperadas ou propagação em redes locais, o impacto seria maior; por agora, essa amplitude de propagação não foi demonstrada publicamente.

As implicações para as organizações que integrem estes robôs nas suas operações incluem a necessidade de reavaliar controlos de acesso físico e lógicos, rever segmentação de rede (aislar robôs em VLANs), e ajustar processos de provisão e autenticação para evitar que uma conta cloud comprometa material de chave de dispositivos alheios.

Medidas concretas e urgentes a tomar pelos operadores do G1 EDU: 1) Aísle imediatamente os robôs G1 EDU de redes não confiáveis e, se possível, desconéctelos temporariamente de Wi-Fi e cloud até que Unitree confirme uma versão adesivo. 2) Desactive Bluetooth ou limite seu alcance físico; se não puder, coloque o robô num espaço controlado onde não tenha acesso público próximo. 3) Mude as credenciais das contas de nuvem relacionadas, active autenticação multifator e reveja registos de recuperação de chaves. 4) Peça ao fabricante a versão exata do firmware que corrige as duas CVE e exija comprobantes de integridade da imagem (firmas digitais). 5) Se você tiver capacidades de segurança, capture imagens forenses e registros do robô antes de aplicar atualizações (para preservar evidências em caso de incidente). 6) Segmente a rede: coloque robôs em sub-redes com regras de firewall rígidas, limitando saídas e acessos administrativos. 7) Mantenha procedimentos de controlo de acesso físico que impeçam terceiros de se aproximarem do suficiente para explorar BLE.

Para administradores de maior escala ou responsáveis pela segurança corporativa, além das ações anteriores, é aconselhável notificar o CSIRT/CERT interno, coordenar com Unitree para receber indicações formais e, se necessário, envolver autoridades de resposta a incidentes. Também convém auditar outros modelos de Unitree implantados na organização por se compartilham componentes vulneráveis.

Fontes e referência prática: Unitree mantém informações de produto e suporte em seu site oficial https://www.unitree.com/. Para compreender as particularidades e limitações do emparelhamento BLE e sua segurança, a especificação oficial de Bluetooth oferece contexto técnico útil https://www.bluetooth.com/learn-about-bluetooth/core-specification/. E para guias operacionais sobre proteção de dispositivos conectados e boas práticas de segurança IoT, a Agência de Cibersegurança e Infraestruturas de EE. A América publica recomendações práticas que podem ser adaptadas ao ambiente de robôs educacionais https://www.cisa.gov/stopthinkconnect/secure-your-devices.

Finalmente, é importante sublinhar a incerteza que ainda existe: a lista pública de versões assinadas e adesivos não foi verificada por terceiros, e Unitree ainda não comunicou publicamente um número de firmware concreto que corrija ambos o CVE em todos os casos. Os operadores devem seguir as comunicações oficiais do fabricante e aplicar adesivos apenas de fontes verificadas; entretanto, as medidas de contenção descritas reduzem o risco e evitam possíveis danos físicos ou compromissos subsequentes.