Plik konfiguracyjny nie powinien niczego uruchamiać

Programista w europejskim zakładzie produkcyjnym pobiera model z publicznego huba, wywołuje from_pretrained i wychodzi na lunch. Biblioteka ściąga wagi, odczytuje opisujący je plik JSON i inicjalizuje model. Nic w tej sekwencji nie wygląda na zgodę na wykonanie cudzego kodu, a programista ustawił już trust_remote_code na False właśnie po to, żeby nią nie było.

Badacze z Pluto Security wykazali, że jednak było. Luka jest oznaczona jako CVE-2026-4372, ma bazową ocenę CVSS 7,8 i została sklasyfikowana w kategorii CWE-502, czyli deserializacja niezaufanych danych. Zamienia rutynowe pobranie modelu w wykonanie dowolnego kodu w Pythonie na maszynie, która to pobranie realizuje, a wymagane działanie użytkownika to nic więcej niż udokumentowany sposób ładowania modelu.

Jak pole metadanych przeszło obok flagi

Flaga chroni pliki z kodem. Atak nadszedł w metadanych. Konstruktor konfiguracji zawierał pętlę, która pobierała każdy klucz i każdą wartość z niezaufanego pliku JSON i zapisywała je bezpośrednio w obiekcie konfiguracji, bez listy dozwolonych wartości i bez walidacji. Wśród pól, które atakujący mógł w ten sposób ustawić, znalazło się jedno o nazwie _attn_implementation_internal, prywatny atrybut wewnętrzny, którego nikt nie uznawał za osiągalny z pobranego pliku.

Kiedy pole to zawierało ciąg znaków o kształcie właściciela i repozytorium, loader kerneli traktował go jako pakiet do pobrania z huba i importował bez żadnych zabezpieczeń. Dowolny kod w Pythonie umieszczony w pliku inicjalizacyjnym tego repozytorium był wtedy uruchamiany. Mechanizm zgody, na którym opierają się programiści, nie został w ogóle odpytany, ponieważ obejmował własny kod modelu, a to nie był własny kod modelu. To był plik ustawień.

Poprawka przyszła pierwsza. Ostrzeżenie potrzebowało kolejnych 81 dni

Daty są tu istotą sprawy. Podatny kod trafił do biblioteki 29 sierpnia 2025 roku i przechodził do każdego release'u przez mniej więcej pół roku. Lukę zgłoszono w ramach programu bug bounty 23 lutego 2026 roku, opiekun projektu otworzył poprawkę 2 marca, a wersja 5.3.0 zamknęła sprawę 4 marca. To szybka i godna uznania reakcja, dziesięć dni od zgłoszenia do release'u z poprawką.

Potem publiczny zapis zamilkł. CVE-2026-4372 opublikowano dopiero 24 maja 2026 roku, 81 dni po tym, jak poprawka znalazła się już w publicznym release. W tej luce czasowej opisano ją w notatkach do release'u jako problem bezpieczeństwa w kernelach, bez numeru CVE, bez oceny istotności i bez wzmianki o tym, że zamyka ona możliwość zdalnego wykonania kodu. Żaden operator, u którego łatanie uruchamiają kanały CVE i komunikaty dostawców, a w Europie dotyczy to większości podmiotów objętych regulacjami, nie otrzymał sygnału, by nadać priorytet aktualizacji, która była już dostępna.

Potem przez te same drzwi włamano się do samego huba

16 lipca 2026 roku Hugging Face ujawnił włamanie do części własnej infrastruktury produkcyjnej. Złośliwy zbiór danych wykorzystał dwie ścieżki wykonania kodu w przetwarzaniu zbiorów, loader zbiorów pobierający zdalny kod oraz wstrzyknięcie szablonu w konfiguracji zbioru, aby uruchomić się na workerze przetwarzającym dane. Stamtąd intruz uzyskał dostęp do node'a, przejął poświadczenia chmurowe i klastrowe, a w ciągu weekendu przeszedł bokiem do kilku wewnętrznych klastrów. Analiza powłamaniowa objęła ponad 17 000 zarejestrowanych działań.

Hugging Face oświadcza, że nie znalazł dowodów na manipulowanie publicznymi modelami, zbiorami danych ani przestrzeniami Spaces, oraz że potwierdził czystość swojego łańcucha dostaw oprogramowania. Incydent należy traktować jako dowód istnienia tej ścieżki eskalacji, a nie jako powód do utraty zaufania do huba. Plik opisujący dane dotarł do workera, a worker dysponował poświadczeniami. Taki jest kształt tego ryzyka i jest on identyczny z kształtem opisanej wyżej luki w konfiguracji.

Co należy rozstrzygnąć przed kolejnym pobraniem modelu

Trzy kontrole, w tej kolejności. Najpierw trzeba ustalić, która wersja biblioteki transformers działa w obrazach treningowych, w notebookach i na agentach budujących, oraz zaktualizować wszystko poniżej 5.3.0. Następnie należy sprawdzić, czy obok niej zainstalowany jest pakiet kernels, ponieważ to on czynił tę ścieżkę możliwą do wykorzystania. Na końcu warto przyjrzeć się temu, jakie poświadczenia znajdują się na maszynach parsujących artefakty modeli i zbiorów danych, ponieważ maszyny te traktuje się zwykle jako zwykłą infrastrukturę przenoszącą dane i w związku z tym nadaje się im szerokie uprawnienia.

Obowiązek zgłoszenia biegnie własnym rytmem niezależnie od wszystkiego. Zgodnie z artykułem 23 dyrektywy NIS2 podmiot objęty jej zakresem przekazuje krajowemu organowi wczesne ostrzeżenie w ciągu 24 godzin od powzięcia wiadomości o poważnym incydencie, pełniejsze zgłoszenie w ciągu 72 godzin oraz sprawozdanie końcowe w ciągu miesiąca. W Polsce odpowiednie wytyczne pochodzą od CERT Polska. Żaden z tych terminów nie zatrzymuje się na czas ustalania, która wersja biblioteki była uruchomiona.

Czytaj dalej: Jedno żądanie mogło przejąć twoją witrynę WordPress  |  Łatanie SharePointa już nie zamyka drzwi