Hugging Face robotikos platforma turi kritinę saugumo spragą: bet kas gali perimti tavo robotą

Įsivaizduok. Tavo laboratorijoje stovi robotas. Jis mokosi paimti objektus, judėti erdvėje, atlikti užduotis. Visa tai valdo DI modelis per Hugging Face LeRobot platformą.

O dabar įsivaizduok, kad kažkas iš kito pasaulio galo gali perimti tą robotą. Be slaptažodžio. Be jokio prisijungimo. Tiesiog nusiuntęs specialiai paruoštą duomenų paketą.

Tai ne kino scenarijus. Tai CVE-2026-25874. Ir tai vyksta dabar.

Kas nutiko su LeRobot

Hugging Face yra milžiniška atviro kodo DI platforma. Jei dirbi su DI modeliais, greičiausiai ją žinai. LeRobot yra jų robotikos projektas, skirtas mokyti robotus atlikti fizines užduotis naudojant mašininį mokymąsi.

Saugumo tyrinėtojai aptiko, kad LeRobot versijoje 0.4.3 yra spraga su CVSS balu 9.3 iš 10. Tai beveik maksimalus pavojingumo lygis.

Problema slypi tame, kaip sistema apdoroja duomenis. LeRobot naudoja Python pickle formatą duomenų perdavimui per gRPC kanalus. Ir čia viskas griūna.

Pickle: senas draugas, kuris tave nuduria

Jei nesi programuotojas, paaiškinsiu paprastai. Pickle yra Python įrankis, kuris paverčia duomenis į kompaktišką formatą siuntimui. Problema ta, kad pickle gali vykdyti kodą. Bet kokį kodą.

Tai tarsi atidaryti laišką, kuris ne tik turi tekstą, bet gali automatiškai paleisti programą tavo kompiuteryje. Ir LeRobot atidaro tokius laiškus iš bet ko, kas prisijungia prie tinklo.

Be šifravimo. Be autentifikacijos. Atvirai.

Kibernetinio saugumo specialistai tai vadina „unsafe deserialization” ir tai yra viena seniausių bei labiausiai žinomų saugumo klaidų. Kad ji atsirastų tokioje platformoje kaip Hugging Face, yra mažų mažiausiai keista.

Ką gali padaryti įsilaužėlis

Per tris gRPC metodus (SendPolicyInstructions, SendObservations, GetActions) atakuotojas gali nusiųsti specialiai paruoštą pickle duomenų paketą. Kai LeRobot serveris jį apdoroja, kodas paleidžiamas automatiškai.

Tai reiškia pilną prieigą prie serverio. Prisimink, kad DI sistemos dažnai veikia su aukštomis privilegijomis ir turi prieigą prie GPU resursų, vidinių tinklų, treniravimo duomenų.

Blogiausiu atveju? Kažkas perima tavo robotą. Fizinį robotą, kuris juda realiame pasaulyje.

Kodėl tai svarbu plačiau

Mes kalbame apie DI saugumą nuolat. Anthropic neseniai parodė, kad DI modeliai gali rasti tūkstančius saugumo spragų senose sistemose. Bet kas nutinka, kai pati DI platforma turi spragą?

Robotika su DI auga greitai. Hannoverio mugėje matėme robotus, kurie jau dirba gamyklų grindyse. Kuo daugiau robotų prijungiame prie interneto ir DI sistemų, tuo didesnis tampa atakos paviršius.

Ir tai ne tik apie laboratorinius robotus. Pramonėje, logistikoje, sandėliuose robotai perima vis daugiau užduočių. Jei jų valdymo sistemos nėra saugios, pasekmės gali būti kur kas rimtesnės nei pavogti duomenys.

Ką daryti, jei naudoji LeRobot

Spraga kol kas neužtaisyta. Bet galima imtis apsaugos priemonių.

Pirma: pakeisk pickle formatą saugesnėmis alternatyvomis. JSON, protobuf arba Hugging Face safetensors formatas tinka.

Antra: įjunk TLS šifravimą gRPC kanaluose. Tai reikalauja pakeisti add_insecure_port() į add_secure_port() su TLS sertifikatu.

Trečia: pridėk autentifikaciją. gRPC interceptoriai ir token pagrindu veikianti prieigos kontrolė uždarys duris atsitiktiniams prisijungimams.

Ir ketvirta, bet ne mažiau svarbu: izoliuok LeRobot sistemas nuo viešo interneto. Jei tavo robotas neprivalo būti pasiekiamas iš išorės, jis neturi būti pasiekiamas iš išorės. Taškas.

Platesnis vaizdas

DI sistemos darosi vis protingesnės, bet jų saugumo pagrindai kartais lieka ties 2015 metų lygiu. Pickle deserializacija be autentifikacijos yra klaida, kurios neturėtų būti jokiame rimtame projekte 2026 metais.

Bet ji yra. Ir tai primena, kad technologijų pasaulyje greitis dažnai eina prieš saugumą.

Gal prieš jungdamas savo kitą DI projektą prie tinklo, patikrink: ar durys užrakintos? Ar langai uždaryti? ES DI aktas reikalauja saugumo, bet sveika nuovoka turi būti pirmiau už reguliavimą.