Falhas no Unitree G1 EDU podem permitir controle remoto do robô com privilégios de root
Duas vulnerabilidades independentes identificadas no robô humanoide Unitree G1 EDU podem abrir caminho para a execução remota de código com privilégios máximos no sistema. Os problemas foram catalogados como CVE-2026-76639 e CVE-2026-76640 e, apesar de explorarem rotas diferentes, podem atingir o Locomotion PC, computador responsável por funções essenciais de operação e movimentação do equipamento.
A pesquisa foi conduzida pelo especialista em segurança Olivier Laflamme. Os resultados mostram que componentes responsáveis por comunicação, provisionamento de rede e autenticação podem ser usados em conjunto para comprometer a infraestrutura computacional do robô.
Path traversal expõe caminho até o sistema principal
A CVE-2026-76639 está relacionada a uma falha de path traversal no componente chat_go. Esse tipo de vulnerabilidade ocorre quando uma aplicação não valida corretamente caminhos de arquivos fornecidos pelo usuário, permitindo acessar áreas do sistema que deveriam permanecer restritas.
No caso analisado, a falha podia ser utilizada para alcançar o bashrunner. A partir desse ponto, um invasor conseguiria executar comandos no Locomotion PC com privilégios de root. Na prática, isso representa controle amplo sobre o computador, incluindo a possibilidade de alterar arquivos, modificar configurações, instalar componentes e interferir em processos responsáveis pelo funcionamento do robô.
Como o Locomotion PC participa diretamente de tarefas operacionais, a consequência ultrapassa o comprometimento de um computador convencional. Uma invasão bem-sucedida poderia afetar o comportamento do equipamento, interromper funções, alterar parâmetros ou criar riscos durante a interação física com pessoas e objetos.
Segunda cadeia começa pela comunicação Bluetooth
A CVE-2026-76640 utiliza uma sequência de exploração mais complexa, com início em uma interação de bootstrap realizada por Bluetooth Low Energy, conhecido como BLE. Segundo a análise, essa etapa inicial poderia ser aceita sem que os dispositivos tivessem concluído previamente o pareamento Bluetooth tradicional.
Isso não significa, entretanto, que qualquer pessoa próxima ao robô conseguiria concluir todo o ataque por meio de uma conexão BLE não autenticada. O conteúdo de bootstrap permanecia protegido, e as etapas seguintes relacionadas ao provisionamento de Wi-Fi dependiam de um estado BLE autenticado pelo aplicativo.
A fragilidade estava na forma como esse estado autenticado poderia ser obtido. Durante os testes, foi identificado que o serviço de nuvem da Unitree aceitava uma conta válida para solicitações de recuperação de chaves, mas não confirmava se a conta pertencia ao robô indicado na requisição.
Essa falha de autorização permitia que uma conta recuperasse material criptográfico associado a outro G1 EDU. Com a chave em mãos, o atacante poderia tentar estabelecer o estado BLE autenticado necessário para acessar as funções de configuração da rede sem fio.
Buffer overflow completa o comprometimento
Depois de alcançar as operações de provisionamento Wi-Fi, a cadeia explorava um buffer overflow no código responsável pela configuração da conexão sem fio. Um buffer overflow acontece quando um programa grava mais dados do que o espaço reservado na memória, o que pode provocar falhas ou permitir a execução de instruções controladas pelo invasor.
Na demonstração apresentada, a exploração também resultava na execução de código com privilégios de root no Locomotion PC. Assim, a segunda vulnerabilidade combinava uma falha de autorização na nuvem, problemas no fluxo de autenticação sem fio e uma vulnerabilidade de memória no dispositivo.
A cadeia demonstra como pequenos erros em componentes distintos podem produzir um impacto maior quando combinados. Uma falha isolada no serviço de nuvem, por exemplo, poderia parecer limitada à exposição de chaves. Porém, quando essas chaves são aceitas por mecanismos locais de provisionamento, elas podem facilitar o acesso a funções muito mais sensíveis.
Pesquisa não comprova ataque em larga escala
O pesquisador informou que limitou os testes de propagação a dois robôs G1 posicionados na mesma sala. Portanto, os resultados não comprovam que as vulnerabilidades possam se espalhar automaticamente entre uma grande quantidade de robôs Unitree.
Também não foi demonstrado um comportamento semelhante ao de um worm em ambientes reais. A possibilidade de propagação em rede depende de fatores como configuração local, isolamento entre dispositivos, permissões, conectividade disponível e existência de outros mecanismos de autenticação.
Ainda assim, o teste reforça a necessidade de tratar robôs conectados como ativos críticos. Equipamentos desse tipo podem reunir interfaces Bluetooth, Wi-Fi, serviços em nuvem, aplicativos móveis e computadores internos, criando uma superfície de ataque mais ampla do que a observada em dispositivos tradicionais.
Correção na nuvem reduziu uma das rotas
A Unitree corrigiu, em julho de 2026, a falha de autorização que permitia solicitar chaves de um robô usando uma conta que não era a proprietária legítima. Com essa alteração, o fluxo exato utilizado na prova de conceito da CVE-2026-76640 deixou de funcionar da mesma maneira.
Na situação descrita na divulgação de 27 de agosto, uma tentativa de explorar a rota dependente da nuvem exigiria uma conta vinculada ao G1 EDU alvo ou que o invasor já tivesse obtido previamente o material criptográfico necessário.
A correção, porém, não elimina automaticamente todas as possibilidades associadas às vulnerabilidades locais. O acesso direto ao equipamento, a exposição de interfaces sem fio e a presença de firmware vulnerável continuam sendo fatores relevantes para a avaliação de risco.
Status do firmware ainda não é totalmente claro
Até a publicação da pesquisa, não havia uma versão específica de firmware confirmada em orientações públicas da Unitree como responsável por corrigir definitivamente as duas vulnerabilidades locais.
Durante a investigação, o equipamento analisado foi atualizado para a versão V1.5.2. No entanto, essa informação não permite concluir quais versões anteriores são vulneráveis nem estabelecer, por si só, qual lançamento corrige integralmente os problemas.
Proprietários e administradores devem evitar presumir que uma atualização específica resolveu todas as falhas sem uma confirmação oficial detalhada. O ideal é acompanhar os comunicados do fabricante, verificar o modelo exato do equipamento e registrar a versão atualmente instalada antes de aplicar mudanças.
Impacto em outros modelos permanece desconhecido
A pesquisa trata especificamente do Unitree G1 EDU. A fabricante diferencia oficialmente o G1 e o G1 EDU como modelos distintos, e não há confirmação de que as mesmas falhas estejam presentes em outros robôs da empresa.
Também não foi estabelecido se componentes semelhantes são utilizados em plataformas como H1, Go2 ou outros produtos. A aplicação das CVEs a equipamentos diferentes depende da arquitetura de software, do firmware, dos serviços de nuvem e dos mecanismos de autenticação usados em cada modelo.
Por esse motivo, não é adequado generalizar os resultados para toda a linha Unitree. Ao mesmo tempo, a existência de componentes compartilhados poderia justificar uma avaliação técnica adicional em produtos que utilizem os mesmos serviços ou bibliotecas.
Medidas recomendadas para operadores
Organizações que utilizam o G1 EDU devem restringir o acesso físico ao robô e evitar deixá-lo permanentemente disponível em áreas públicas ou sem supervisão. A proximidade física pode ser relevante em ataques que exploram Bluetooth, especialmente durante processos de configuração ou manutenção.
Também é recomendável separar o robô de redes corporativas sensíveis. Uma rede exclusiva, com regras de firewall e monitoramento, reduz o impacto de um eventual comprometimento e dificulta o acesso a servidores internos.
As credenciais de contas associadas ao equipamento devem ser únicas, fortes e protegidas por autenticação adicional quando disponível. Contas antigas, compartilhadas ou usadas em vários robôs aumentam o risco de abuso e dificultam a identificação do responsável por uma ação.
Monitoramento pode ajudar na detecção
Além de atualizar o firmware e os componentes disponíveis, os responsáveis devem monitorar alterações inesperadas de configuração, novas conexões Bluetooth, mudanças no provisionamento Wi-Fi e comportamentos anormais do Locomotion PC.
Sinais como reinicializações frequentes, movimentação fora do padrão, perda repentina de conectividade, modificações não autorizadas em arquivos e consumo incomum de recursos podem indicar uma tentativa de interferência.
Em ambientes de pesquisa, ensino ou demonstração, é prudente manter uma barreira física e um procedimento de desligamento de emergência. A segurança digital de um robô humanoide precisa considerar também a possibilidade de consequências mecânicas, como movimentos indevidos ou interrupções durante uma tarefa.
Segurança de robôs exige abordagem integrada
As descobertas evidenciam que vulnerabilidades conhecidas, como path traversal, buffer overflow e falhas de autorização, assumem uma dimensão diferente quando estão presentes em sistemas capazes de perceber e interagir fisicamente com o ambiente.
A proteção desses equipamentos deve abranger o software embarcado, os computadores internos, os aplicativos móveis, os serviços de nuvem, as interfaces sem fio e os controles de acesso físico. Também é necessário manter inventário dos dispositivos, acompanhar versões de firmware e estabelecer procedimentos claros para resposta a incidentes.
O caso do Unitree G1 EDU mostra ainda que a segurança não depende apenas de corrigir uma falha isolada. A combinação entre problemas aparentemente distintos pode formar uma cadeia de ataque capaz de alcançar componentes críticos. Por isso, avaliações periódicas e testes independentes são fundamentais antes de colocar robôs conectados em operação próxima ao público ou integrados a redes corporativas.