Unitree G1 EDU: due falle possono portare al controllo root del robot

La disclosure di sicurezza UniBLEed, pubblicata nell’agosto 2026, ha descritto due catene d’attacco separate che interessano i firmware del robot umanoide Unitree G1 EDU fino alla versione 1.5.2. Una può iniziare con un aggressore non autenticato nel raggio Bluetooth; l’altra sfrutta servizi accessibili da una rete adiacente e la funzione chat_go per la gestione della base di conoscenza. In entrambi i casi, l’obiettivo finale descritto è il controllo root del Locomotion PC del robot. 158

La distinzione è importante: l’impatto non si limiterebbe a un’applicazione o a una sessione Bluetooth compromessa. Il Locomotion PC gestisce infatti componenti sensibili per il funzionamento del robot, tra cui motori, telecamere, audio e funzioni vocali. 513

CVE-2026-76640: dalla vicinanza Bluetooth al controllo root

La vulnerabilità BLE è la più insolita delle due perché non richiede che l’aggressore abbia già accesso alla rete locale del robot. Secondo le informazioni pubblicate, un attaccante fisicamente vicino potrebbe interagire con funzionalità GATT esposte senza effettuare il pairing e senza possedere credenziali del robot. 5813

La catena descritta combina più debolezze:

• Un endpoint cloud di Unitree avrebbe consentito a un account gratuito di recuperare la chiave AES-128 di un G1 senza verificare adeguatamente che l’account fosse effettivamente associato al robot bersaglio. 811
• Con quella chiave, l’aggressore avrebbe potuto raggiungere operazioni BLE protette, inserire una chiave precondivisa e attivare un percorso alternativo per la configurazione del Wi-Fi. 811
• La gestione non sicura dei dati di provisioning — inclusa una variabile non racchiusa tra virgolette in un heredoc — avrebbe potuto essere combinata con difetti nello stack di provisioning BLE e Wi-Fi per arrivare all’esecuzione arbitraria di comandi con privilegi root. 511

Le descrizioni pubbliche della vulnerabilità riportano inoltre un componente di buffer overflow nel percorso che elabora il nome della rete Wi-Fi (SSID). L’overflow potrebbe corrompere una voce adiacente usata per la distribuzione dei puntatori a funzione; questa sarebbe poi sfruttata per invocare dati controllati dall’aggressore tramite system() con privilegi root. 35

Perché la distanza fisica conta

L’aggressore dovrebbe trovarsi abbastanza vicino da comunicare via Bluetooth, ma non necessariamente disporre di credenziali o aver completato il pairing. Il profilo di rischio cambia quindi per i robot impiegati in dimostrazioni pubbliche, laboratori, magazzini o strutture condivise.

La ricerca ha inoltre evidenziato un possibile scenario di propagazione simile a quello di un worm: un G1 compromesso potrebbe, in teoria, cercare e colpire altre unità vulnerabili nelle vicinanze. Si tratta di una conseguenza potenziale della catena d’attacco, non della prova che un worm sia stato distribuito realmente. 58

La preoccupazione è rafforzata da precedenti analisi su firmware Unitree correlati, nelle quali è stata documentata l’iniezione di comandi attraverso dati Wi-Fi manipolati elaborati dopo un’interazione di provisioning BLE.

CVE-2026-76639: il percorso separato attraverso chat_go

CVE-2026-76639 utilizza un punto d’ingresso diverso. Il National Vulnerability Database (NVD) descrive i firmware G1 EDU fino alla versione 1.5.2 come vulnerabili a una catena non autenticata di esecuzione remota di codice, accessibile da una rete adiacente, che combina tre debolezze: un bridge WebRTC-DDS esposto sulla porta TCP 9991, una chiave AES-128 statica conservata con permessi eccessivamente permissivi e una vulnerabilità di path traversal nell’API di caricamento della base di conoscenza chat_go. 1

In sintesi, il difetto di attraversamento dei percorsi potrebbe consentire di collocare un file malevolo in una directory autorizzata da bashrunner. Il servizio lo eseguirebbe quindi con privilegi root, trasformando un problema di scrittura arbitraria dei file in un’esecuzione di codice. 14

Questo percorso non dipende dalla presenza dell’aggressore accanto al robot e non richiede necessariamente un attacco Bluetooth. L’esposizione pratica dipende invece da quanto sono raggiungibili i servizi adiacenti alla rete e dalla possibilità che dispositivi non attendibili comunichino con essi.

Cosa potrebbe essere esposto dopo la compromissione

L’accesso root al Locomotion PC potrebbe dare il controllo sui software collegati alle funzioni principali del robot. Tra le capacità rilevanti indicate nelle analisi figurano locomozione e motori, telecamere, microfoni, riproduzione audio e funzioni vocali. 513

Le conseguenze sarebbero quindi sia informatiche sia fisiche: un robot compromesso potrebbe potenzialmente essere usato per sorveglianza, riproduzione audio o vocale non autorizzata, interruzione del servizio o movimenti non sicuri. Le informazioni disponibili confermano la sensibilità dei sistemi coinvolti, ma non dimostrano che uno specifico G1 sia stato sfruttato né che si sia verificato un incidente pericoloso nel mondo reale.

La risposta di Unitree e ciò che non è ancora chiaro

Le informazioni pubbliche riferiscono che Unitree ha convalidato i risultati e rilasciato delle patch. 6 Altre ricostruzioni descrivono l’aggiunta, nel luglio 2026, di un controllo che verifica l’associazione tra account e robot. 12 Tuttavia, le evidenze disponibili non includono un avviso ufficiale del produttore che colleghi ciascun CVE a una specifica versione corretta del firmware G1 EDU.

L’intervallo indicato nei materiali relativi alle CVE riguarda i firmware fino alla versione 1.5.2. 15 Non è stata verificata in modo indipendente una release precisa che risolva definitivamente ogni elemento di entrambe le catene. 8

Per questo motivo, gli operatori non dovrebbero presumere che un generico aggiornamento alla versione “più recente” chiuda entrambe le vulnerabilità senza controllare la versione installata e ottenere una conferma da Unitree.

Cosa dovrebbero fare gli operatori del G1 EDU

1. Verificare la correzione con Unitree. Chiedere quali versioni esatte del firmware risolvono sia CVE-2026-76639 sia CVE-2026-76640, quindi controllare la versione installata su ogni robot.
2. Ridurre l’esposizione fisica. Fino alla conferma dell’avvenuta correzione, tenere i robot interessati lontani da persone non affidabili e da altre unità G1 vulnerabili. Disabilitare inoltre il provisioning BLE quando ciò è compatibile con le esigenze operative.
3. Segmentare la rete. Collocare i sistemi G1 su reti isolate e soggette a controllo degli accessi, bloccando le connessioni in ingresso non necessarie verso i servizi di gestione, WebRTC/DDS e provisioning.
4. Limitare i caricamenti di file. Disabilitare o restringere, ove possibile, i caricamenti della base di conoscenza tramite chat_go. Verificare inoltre le directory autorizzate da bashrunner e i relativi file di servizio per individuare modifiche inattese.
5. Analizzare ogni possibile esposizione. Considerare una compromissione non spiegata come un potenziale incidente a livello root: ruotare credenziali e chiavi pertinenti, esaminare log e modifiche al filesystem e, se necessario, reinstallare il robot da una fonte Unitree affidabile.

La lezione centrale di UniBLEed è che la sicurezza di un robot dipende dall’intero stack di controllo connesso. Un’interfaccia BLE, un controllo di autorizzazione sul cloud, uno script di provisioning o una funzione di caricamento legata all’intelligenza artificiale possono diventare una porta d’accesso al sistema che governa la macchina fisica quando autenticazione e privilegi di esecuzione non vengono applicati in modo coerente.