Krytyczna luka CVE-2026-25874 w Hugging Face LeRobot pozwala na zdalne wykonanie kodu bez uwierzytelnienia

Co znajdziesz w tym artykule?

1 Wprowadzenie do problemu / definicja
2 W skrócie
3 Kontekst / historia
4 Analiza techniczna
5 Konsekwencje / ryzyko
6 Rekomendacje
7 Podsumowanie
8 Źródła

Wprowadzenie do problemu / definicja

CVE-2026-25874 to krytyczna podatność bezpieczeństwa wykryta w frameworku Hugging Face LeRobot, wykorzystywanym w projektach z obszaru robotyki i systemów AI. Błąd wynika z niebezpiecznej deserializacji niezaufanych danych i może prowadzić do zdalnego wykonania kodu bez potrzeby uwierzytelnienia.

Problem dotyczy mechanizmu przetwarzania danych w asynchronicznym pipeline inferencyjnym. W praktyce oznacza to, że atakujący, który uzyska dostęp do podatnego interfejsu sieciowego, może przygotować złośliwy ładunek i uruchomić własny kod na systemie obsługującym LeRobot.

W skrócie

Podatność została oznaczona jako CVE-2026-25874.
Jej ocena CVSS 9.3 klasyfikuje ją jako krytyczną.
Luka umożliwia nieuwierzytelnione zdalne wykonanie kodu.
Źródłem problemu jest użycie pickle.loads() do deserializacji danych pochodzących z sieci.
Według publicznych opisów zagrożone są wydania LeRobot do wersji 0.5.1.
Poprawka ma zostać dostarczona w linii 0.6.0.

Kontekst / historia

LeRobot to otwartoźródłowa platforma wspierająca rozwój i wdrażanie systemów robotycznych sterowanych przez modele AI. Tego typu środowiska często działają w infrastrukturze mającej dostęp do danych, modeli, kluczy API, zasobów obliczeniowych oraz sieci wewnętrznych.

Publiczne informacje o luce pojawiły się w kwietniu 2026 roku. Istotne jest to, że podatność nie dotyczy wyłącznie typowego komponentu aplikacyjnego, ale elementu odpowiedzialnego za komunikację i obsługę procesów inferencyjnych. W środowiskach robotycznych zwiększa to wagę incydentu, ponieważ skutki mogą obejmować nie tylko system IT, ale również procesy operacyjne zależne od działania urządzeń fizycznych.

Analiza techniczna

Rdzeniem podatności jest zastosowanie formatu pickle do odtwarzania obiektów pochodzących z niezaufanego źródła. W Pythonie pickle nie jest bezpiecznym formatem serializacji dla danych przesyłanych przez sieć, ponieważ podczas deserializacji może dojść do wykonania zdefiniowanej logiki. To klasyczny przykład błędu CWE-502, czyli deserializacji niezaufanych danych.

W opisanym scenariuszu podatny komponent odbiera dane za pośrednictwem gRPC, a następnie przekazuje je bezpośrednio do pickle.loads(). Jeśli napastnik przygotuje odpowiednio spreparowany payload, wykonanie kodu następuje już na etapie przetwarzania danych, zanim zadziałają jakiekolwiek późniejsze kontrole logiki aplikacji.

W publicznych analizach wskazano, że z podatnym przepływem mogą być związane metody RPC takie jak SendPolicyInstructions, SendObservations oraz GetActions. Szczególne znaczenie ma komponent async inference PolicyServer, który przetwarza dane wejściowe w kontekście modeli sterujących działaniem systemów robotycznych.

Od strony operacyjnej jest to bardzo niebezpieczny wzorzec. Usługa nasłuchuje w sieci, przyjmuje binarne dane i wykonuje ich niebezpieczną deserializację bez odpowiednich zabezpieczeń. Jeżeli proces działa z szerokimi uprawnieniami lub ma dostęp do wrażliwych zasobów, skutkiem może być pełne przejęcie hosta.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją podatności jest możliwość uruchomienia dowolnego kodu na serwerze lub kliencie korzystającym z podatnego mechanizmu. To otwiera drogę do przejęcia systemu, kradzieży danych oraz dalszych działań wewnątrz infrastruktury.

przejęcie hosta uruchamiającego PolicyServer,
kradzież sekretów, w tym kluczy API, poświadczeń SSH i plików modeli,
ruch lateralny w sieci wewnętrznej,
instalacja złośliwego oprogramowania lub mechanizmów trwałości,
zakłócenie działania usług inferencyjnych,
manipulacja logiką sterowania robotem lub procesem operacyjnym.

W środowiskach produkcyjnych i laboratoryjnych wpływ może być większy niż w przypadku klasycznej luki RCE w aplikacji webowej. Jeżeli podatny komponent jest częścią łańcucha sterowania urządzeniem fizycznym, incydent może przełożyć się również na bezpieczeństwo procesów i dostępność systemów robotycznych.

Rekomendacje

Najważniejszym działaniem jest aktualizacja do wersji zawierającej poprawkę, gdy tylko będzie ona dostępna i zweryfikowana w środowisku docelowym. Do tego czasu wszystkie instancje LeRobot wystawione do sieci należy traktować jako obarczone wysokim ryzykiem.

ograniczyć ekspozycję usług LeRobot wyłącznie do zaufanych segmentów sieci,
zablokować publiczny dostęp do portów gRPC za pomocą firewalla, ACL lub VPN,
wyłączyć komponenty async inference, jeśli nie są niezbędne,
zastąpić niebezpieczną deserializację bezpieczniejszym formatem, takim jak protobuf lub JSON,
wymusić TLS i silne uwierzytelnianie klientów gRPC,
uruchamiać usługę z minimalnymi uprawnieniami, najlepiej w kontenerze lub sandboxie,
monitorować podejrzane procesy potomne, nietypowy ruch wychodzący i operacje na katalogach tymczasowych,
przeanalizować logi pod kątem nietypowych wywołań RPC i anomalii w działaniu PolicyServer.

Warto również przeprowadzić przegląd innych projektów AI i ML pod kątem użycia pickle w ścieżkach sieciowych. Przypadek LeRobot pokazuje, że klasyczne błędy deserializacji nadal pojawiają się także w nowoczesnych środowiskach sztucznej inteligencji.

Podsumowanie

CVE-2026-25874 to przykład krytycznej luki w warstwie komunikacji i przetwarzania danych w środowisku AI oraz robotyki. Połączenie niezaufanego wejścia, gRPC bez odpowiednich zabezpieczeń i użycia pickle.loads() tworzy prostą ścieżkę do zdalnego wykonania kodu bez uwierzytelnienia.

Dla zespołów bezpieczeństwa oznacza to konieczność pilnej oceny ekspozycji, ograniczenia dostępu do podatnych usług oraz przygotowania planu aktualizacji. W środowiskach, w których LeRobot odpowiada za procesy o znaczeniu operacyjnym, podatność powinna być traktowana priorytetowo.