Krytyczne luki w Hugging Face Diffusers mogą prowadzić do zdalnego wykonania kodu podczas ładowania modeli

Wprowadzenie do problemu / definicja

Biblioteki i repozytoria modeli AI coraz częściej stają się istotnym elementem łańcucha dostaw oprogramowania. Najnowsze ustalenia dotyczące Hugging Face Diffusers pokazują, że pozornie pasywne artefakty modelu, takie jak konfiguracje, komponenty pipeline’ów i dodatkowe pliki Python, mogą zostać wykorzystane do uruchomienia nieautoryzowanego kodu na systemie ofiary.

Problem dotyczy mechanizmu ładowania modeli oraz obejścia zabezpieczenia trust_remote_code, które miało blokować wykonywanie niezaufanego kodu. W praktyce oznacza to, że samo pobranie i inicjalizacja spreparowanego repozytorium modelu może otworzyć drogę do pełnej kompromitacji środowiska wykonawczego.

W skrócie

W bibliotece Hugging Face Diffusers ujawniono trzy luki wysokiego ryzyka, określane zbiorczo jako FaceHugger. Błędy umożliwiają obejście mechanizmu trust_remote_code=False i doprowadzenie do wykonania dowolnego kodu przy ładowaniu złośliwie przygotowanego repozytorium modelu.

• Podatności obejmują dwa przypadki wstrzyknięcia kodu oraz jeden scenariusz wyścigu typu TOCTOU.
• Najbardziej narażone są środowiska korzystające ze starszych wersji biblioteki Diffusers.
• Problem został zaadresowany w wersji Diffusers 0.38.0.
• Ryzyko dotyczy szczególnie organizacji automatycznie pobierających modele z publicznych źródeł.

Kontekst / historia

Diffusers to popularna biblioteka Pythona wykorzystywana do pracy z modelami dyfuzyjnymi generującymi obrazy, audio i wideo. Ze względu na szerokie zastosowanie w środowiskach badawczych, developerskich i produkcyjnych, stała się ważnym składnikiem ekosystemu AI oraz organizacyjnego łańcucha dostaw.

Kluczowym mechanizmem bezpieczeństwa w tym obszarze jest parametr trust_remote_code. Jego zadaniem jest kontrolowanie, czy niestandardowy kod osadzony w repozytorium modelu może zostać wykonany podczas operacji from_pretrained(). Teoretycznie ustawienie tej opcji na False powinno uniemożliwiać uruchamianie niezweryfikowanego kodu. Badacze wykazali jednak, że w określonych warunkach ochrona ta może zostać ominięta.

Analiza techniczna

Rdzeń problemu wynika z rozdzielenia procesu walidacji i faktycznego użycia pobieranych artefaktów. Badacze opisali ten mechanizm jako klasę błędów TOCTOU, czyli Time-of-Check to Time-of-Use. Oznacza to, że biblioteka przeprowadza kontrolę bezpieczeństwa na jednym etapie, ale rzeczywiste użycie komponentów następuje później, po dodatkowych operacjach pobierania lub interpretacji zawartości repozytorium.

W analizowanym scenariuszu ładowanie modelu nie stanowi jednej atomowej operacji. Część danych jest sprawdzana wcześniej, a część może zostać pobrana lub zinterpretowana dopiero w późniejszej fazie. To tworzy warunki, w których mechanizm bezpieczeństwa nie obejmuje wszystkich elementów wpływających na końcowe wykonanie pipeline’u.

Opisane podatności obejmują trzy luki:

• CVE-2026-44827 o ocenie CVSS 8.8, związane z wstrzyknięciem kodu przez przepływ custom_pipeline, w tym przez spreparowaną nazwę pipeline’u, mimo użycia trust_remote_code=False.
• CVE-2026-45804 o ocenie CVSS 7.5, wynikające z warunku wyścigu między etapami pobierania artefaktów z repozytorium, co umożliwia podmianę konfiguracji i wykonanie kodu.
• CVE-2026-44513 o ocenie CVSS 8.8, również pozwalające na obejście ograniczeń trust_remote_code i załadowanie złośliwego kodu przez niestandardowy pipeline.

Z technicznego punktu widzenia kluczowe jest to, że repozytorium modelu AI nie powinno być traktowane wyłącznie jako zbiór wag lub danych. Jeżeli proces ładowania interpretuje pliki konfiguracyjne, komponenty pipeline’u i dodatkowe moduły Python, repozytorium staje się nośnikiem logiki wykonywalnej. W takim modelu atakujący może przygotować artefakt, który uruchomi się w kontekście procesu odpowiedzialnego za inferencję, testy, build lub pipeline CI/CD.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem jest możliwość zdalnego wykonania kodu na maszynie ładującej model. W zależności od miejsca uruchomienia może to oznaczać przejęcie stacji roboczej badacza, serwera inferencyjnego, runnera CI/CD, kontenera budującego obrazy lub innego komponentu środowiska MLOps.

Ryzyko jest szczególnie wysokie dla organizacji, które automatycznie pobierają modele z publicznych repozytoriów, integrują Diffusers z pipeline’ami produkcyjnymi, uruchamiają ładowanie modeli z podwyższonymi uprawnieniami lub nie izolują środowisk AI od infrastruktury krytycznej.

• kradzież sekretów, tokenów dostępowych i kluczy API,
• modyfikacja obrazów kontenerowych i pipeline’ów buildowych,
• trwałe osadzenie złośliwego kodu w procesach MLOps,
• lateral movement w sieci organizacji,
• naruszenie integralności modeli i wyników inferencji.

Z perspektywy bezpieczeństwa łańcucha dostaw AI incydent ten potwierdza, że granica między modelem a kodem wykonawczym staje się coraz bardziej płynna.

Rekomendacje

Podstawowym działaniem naprawczym jest aktualizacja biblioteki do wersji Diffusers 0.38.0 lub nowszej. Organizacje powinny również przeprowadzić przegląd wszystkich środowisk, w których wykorzystywana jest funkcja DiffusionPipeline.from_pretrained, szczególnie jeśli używane są niestandardowe pipeline’y.

• Ograniczyć ładowanie modeli i pipeline’ów wyłącznie do zaufanych, audytowanych źródeł.
• Unikać wskazywania custom_pipeline do repozytorium innego niż główne źródło modelu bez wcześniejszej analizy.
• Przed użyciem lokalnego snapshotu sprawdzać obecność nieoczekiwanych plików .py w katalogach projektu.
• Uruchamiać procesy inferencyjne i testowe w odizolowanych środowiskach z minimalnymi uprawnieniami.
• Monitorować ruch wychodzący i anomalie procesów podczas pobierania i inicjalizacji modeli.
• Traktować repozytoria modeli AI jako niezaufany kod w politykach bezpieczeństwa i procedurach DevSecOps.
• Uwzględnić skanowanie zależności AI/ML w procesach SBOM, SCA oraz kontroli łańcucha dostaw.

Dodatkowo warto wdrożyć polityki dopuszczające do użycia jedynie zatwierdzone snapshoty modeli, z hashowaniem artefaktów i kontrolą integralności. Takie podejście ogranicza ryzyko podmiany zawartości między etapem weryfikacji a faktycznym użyciem.

Podsumowanie

Luki FaceHugger w Hugging Face Diffusers pokazują, że bezpieczeństwo ekosystemu AI nie może opierać się na założeniu, że model jest jedynie pasywnym plikiem danych. Jeżeli proces ładowania dopuszcza interpretację niestandardowych komponentów, każda słabość w walidacji może przekształcić zwykły import modelu w wektor początkowego dostępu.

Dla zespołów bezpieczeństwa oznacza to konieczność traktowania narzędzi AI i repozytoriów modeli tak samo jak innych elementów łańcucha dostaw oprogramowania. Aktualizacja Diffusers, ograniczenie zaufania do zewnętrznych artefaktów oraz izolacja środowisk wykonawczych powinny być priorytetem dla organizacji korzystających z tego stosu technologicznego.

Źródła

1. The Hacker News — https://thehackernews.com/2026/08/hugging-face-diffusers-flaws-could-let.html
2. NVD: CVE-2026-44827 — https://nvd.nist.gov/vuln/detail/CVE-2026-44827
3. Hugging Face Diffusers Releases — https://github.com/huggingface/diffusers/releases
4. PyPI: diffusers 0.38.0 — https://pypi.org/project/diffusers/0.38.0/
5. Hugging Face Documentation: Community pipelines and components — https://huggingface.co/docs/diffusers/main/using-diffusers/custom_pipeline_overview