Luki w Hugging Face Diffusers pozwalały ominąć trust_remote_code i uruchomić zdalny kod

Wprowadzenie do problemu / definicja

W bibliotece Hugging Face Diffusers wykryto poważne luki bezpieczeństwa, które umożliwiały obejście mechanizmu trust_remote_code. Funkcja ta miała chronić użytkowników przed nieświadomym uruchamianiem niestandardowego kodu pobieranego razem z modelami generatywnymi, jednak w praktyce wybrane ścieżki ładowania pozwalały ominąć tę kontrolę.

Problem jest istotny, ponieważ Diffusers jest szeroko stosowane do uruchamiania modeli obrazu, audio i wideo, a więc w środowiskach badawczych, developerskich i produkcyjnych. W efekcie podatność wpisuje się w rosnące ryzyko związane z bezpieczeństwem łańcucha dostaw dla systemów AI i ML.

W skrócie

Ujawnione podatności dotyczyły wersji Diffusers wcześniejszych niż 0.38.0 i mogły prowadzić do wykonania dowolnego kodu Python podczas ładowania spreparowanych repozytoriów modeli lub lokalnych snapshotów.

• Mechanizm trust_remote_code można było ominąć w kilku scenariuszach ładowania pipeline’ów.
• Atakujący mógł przygotować złośliwy komponent modelu lub niestandardowy pipeline.
• W jednym z wariantów możliwe było automatyczne załadowanie pliku None.py.
• Najważniejszym działaniem naprawczym jest aktualizacja do wersji 0.38.0 lub nowszej.

Kontekst / historia

Ryzyko wykonywania kodu przy ładowaniu modeli nie jest nowym zjawiskiem. Nowoczesne ekosystemy ML coraz częściej traktują model jako zestaw plików zawierających nie tylko wagi, lecz także logikę uruchomieniową, klasy pomocnicze i dodatkowe komponenty.

To podejście zwiększa elastyczność i ułatwia wdrażanie niestandardowych rozwiązań, ale jednocześnie poszerza powierzchnię ataku. W przypadku Diffusers mechanizm trust_remote_code miał być świadomą bramką bezpieczeństwa, która wymaga zgody użytkownika na wykonanie zdalnego kodu. Ujawnione błędy pokazały jednak, że kontrola nie obejmowała wszystkich ścieżek wykonania.

Analiza techniczna

Główna przyczyna problemu miała charakter architektoniczny. Kontrola bezpieczeństwa została osadzona w logice pobierania zasobów, a nie bezpośrednio w miejscu faktycznego ładowania modułów dynamicznych. W praktyce oznaczało to, że ścieżki omijające lub skracające etap pobierania mogły jednocześnie ominąć również walidację bezpieczeństwa.

Pierwszy scenariusz dotyczył użycia parametru custom_pipeline wskazującego inne repozytorium niż główne repo modelu. W takim przypadku weryfikacja odnosiła się do jednego zestawu plików, natomiast wykonywany kod pochodził z innego źródła. Powstawało więc rozdzielenie między obiektem walidowanym a obiektem faktycznie uruchamianym.

Drugi wariant obejmował ładowanie z lokalnego snapshotu przy jednoczesnym użyciu zdalnego custom_pipeline. Ponieważ ścieżka lokalna nie aktywowała pełnego procesu odpowiedzialnego za kontrolę bezpieczeństwa, zdalny kod mógł zostać uruchomiony mimo założonej polityki blokującej.

Trzeci scenariusz dotyczył lokalnych snapshotów zawierających niestandardowe komponenty wskazane w pliku model_index.json, na przykład własne moduły dla wybranych elementów pipeline’u. Również tutaj lokalna ścieżka ładowania omijała kluczowy punkt egzekwowania reguły trust_remote_code.

Osobny, lecz powiązany problem wynikał z obsługi parametru custom_pipeline, gdy nie został on jawnie przekazany. W podatnej logice wartość None mogła zostać przekształcona do postaci None.py. Jeśli taki plik znajdował się w repozytorium wraz z odpowiednio przygotowaną konfiguracją, standardowe wywołanie funkcji ładującej mogło pobrać i uruchomić złośliwy moduł bez dodatkowych argumentów ze strony ofiary.

Z perspektywy bezpieczeństwa są to błędy prowadzące do zdalnego wykonania kodu oraz naruszenia założeń mechanizmu ochronnego. Problem wykracza więc poza pojedynczą bibliotekę i pokazuje szersze wyzwania związane z zaufaniem do artefaktów ML.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem podatności jest możliwość uruchomienia dowolnego kodu Python w środowisku, które ładuje model. Jeżeli taki proces działa z szerokimi uprawnieniami, atak może prowadzić do przejęcia serwera inferencyjnego, kradzieży sekretów, modyfikacji wyników działania modeli lub wdrożenia trwałych mechanizmów obecności.

Ryzyko rośnie szczególnie w organizacjach, które automatycznie pobierają modele z publicznych repozytoriów i traktują je bardziej jak dane niż wykonywalny kod. Dotyczy to zwłaszcza notebooków badawczych, pipeline’ów CI/CD, współdzielonych workerów GPU oraz środowisk bez izolacji kontenerowej i restrykcyjnej kontroli ruchu wychodzącego.

• przejęcie procesu odpowiedzialnego za inferencję,
• wyciek kluczy API, tokenów i innych sekretów,
• modyfikacja zachowania modelu lub wyników jego pracy,
• ruch boczny w infrastrukturze po uzyskaniu dostępu do hosta,
• utrwalenie złośliwej obecności w środowisku produkcyjnym.

Rekomendacje

Podstawowym krokiem naprawczym jest aktualizacja biblioteki Hugging Face Diffusers do wersji 0.38.0 lub nowszej. To najważniejsze działanie ograniczające ryzyko wykorzystania opisanych luk.

Równolegle warto wdrożyć podejście defense-in-depth i potraktować modele oraz pipeline’y jako aktywny element kodu, a nie wyłącznie pasywny artefakt danych.

• ograniczyć ładowanie modeli do zaufanych i zatwierdzonych repozytoriów,
• stosować pinning wersji, hashy i snapshotów zamiast dynamicznego pobierania najnowszych zasobów,
• skanować repozytoria modeli pod kątem dodatkowych plików Python i wpisów w model_index.json,
• uruchamiać pipeline’y w odizolowanych kontenerach lub sandboxach z minimalnymi uprawnieniami,
• blokować zbędny ruch sieciowy wychodzący z workerów obsługujących modele,
• monitorować procesy potomne, nietypowe połączenia i dostęp do sekretów podczas inicjalizacji,
• rozdzielać środowiska testowe i produkcyjne dla eksperymentów z nowymi modelami,
• włączyć przegląd bezpieczeństwa także dla zewnętrznych artefaktów ML.

Podsumowanie

Luki w Hugging Face Diffusers pokazują, że bezpieczeństwo narzędzi AI coraz mocniej przypomina klasyczne problemy software supply chain. Mechanizm trust_remote_code miał pełnić rolę zabezpieczenia przed nieautoryzowanym wykonaniem kodu, jednak błędy implementacyjne umożliwiły jego obejście w kilku scenariuszach.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że repozytoria modeli, snapshoty i niestandardowe pipeline’y wymagają takich samych kontroli jak zależności programistyczne. Aktualizacja biblioteki oraz wdrożenie izolacji, walidacji i monitoringu powinny być traktowane jako priorytet.

Źródła

1. NVD – CVE-2026-44513 — https://nvd.nist.gov/vuln/detail/CVE-2026-44513
2. NVD – CVE-2026-44827 — https://nvd.nist.gov/vuln/detail/CVE-2026-44827
3. Infosecurity Magazine – Bugs in Hugging Face Diffusers Bypass Custom Code Safeguard — https://www.infosecurity-magazine.com/news/hugging-face-diffusers-trust/
4. GitHub – huggingface/diffusers Releases — https://github.com/huggingface/diffusers/releases
5. GitHub – Security considerations for trust_remote_code=True, Discussion #12033 — https://github.com/huggingface/diffusers/discussions/12033