Xinference CVE-2026-76841: model z Hugging Face był zależnością wykonawczą
Sześć loaderów ufało zdalnemu kodowi modelu. Analiza trust_remote_code, wersji 2.12.0, uprawnień launch model i izolacji workerów AI.
- AUTOR
- Karol Rapacz / CEO Breachroad · OSCP · PNPT
- PUBLIKACJA
- 24 sierpnia 2026
- CZAS CZYTANIA
- 19 min czytania
- TEMAT
- Bezpieczeństwo AI
CVE-2026-76841 zostało opublikowane 24 sierpnia i dotyczy Xinference przed wersją 2.12.0. W sześciu ścieżkach ładowania modeli opcja Hugging Face trust_remote_code była ustawiona na True bezwarunkowo albo pozostawała domyślnie włączona. Użytkownik mający prawo uruchomić model mógł zarejestrować nieznaną rodzinę i wskazać kontrolowane repozytorium, a loader importował kod Pythona zadeklarowany przez metadane modelu.
Rezultatem jest zdalne wykonanie kodu w procesie workera. Rekord przyznaje luce CVSS 4.0: 8,7 (High) i CVSS 3.1: 8,8 (High). Poprawka znajduje się w Xinference 2.12.0, wydanym 4 lipca. Najważniejsza zmiana nie polega na lepszym skanowaniu pliku modelu, lecz na wyłączeniu zaufania do zdalnego kodu dla modeli użytkownika, dopóki operator świadomie go nie włączy.
Model nie zawsze jest tylko zbiorem wag
W typowym opisie systemu AI model bywa przedstawiany jako dane: tensor wag, tokenizer i konfiguracja. Ekosystem Hugging Face obsługuje jednak architektury wymagające niestandardowej implementacji. Repozytorium może przez pole auto_map w tokenizer_config.json wskazać klasę Pythona, którą biblioteka ma pobrać i zaimportować. trust_remote_code=True jest zgodą na wykonanie tej implementacji.
Ta możliwość ma legalne zastosowanie. Pozwala uruchamiać nowe architektury przed włączeniem ich do standardowej biblioteki Transformers. Z punktu widzenia bezpieczeństwa repozytorium modelu staje się jednak odpowiednikiem pakietu kodu lub obrazu kontenera. Jego autor, commit i zawartość muszą należeć do łańcucha dostaw o właściwym poziomie zaufania.
W podatnej ścieżce Xinference użytkownik mógł zarejestrować nieznany model oraz kontrolować lokalizację modelu. Funkcja automatycznego rozpoznawania typu prowadziła do AutoTokenizer.from_pretrained(). Po odczytaniu auto_map biblioteka ładowała klasę z repozytorium, a import wykonywał kod w workerze. Nie jest to „prompt injection” ani problem z odpowiedzią LLM; to wykonanie zwykłego Pythona podczas przygotowania modelu.
Sześć miejsc, jeden błąd polityki
Advisory i poprawka wskazują sześć loaderów: ścieżki rerank, embedding i rerank oparte na Sentence Transformers, integrację FlagEmbedding oraz dwie ścieżki LLM Transformers. Rozproszenie miało znaczenie, ponieważ naprawa tylko jednego wywołania pozostawiłaby alternatywną drogę do tej samej niebezpiecznej funkcji.
Wspólnym problemem nie była konkretna architektura modelu, lecz brak centralnej decyzji polityki. Każdy loader lokalnie zakładał, że zdalny kod można uruchomić. Gdy platforma dodaje kolejne backendy, takie kopiowane wartości domyślne dryfują i trudno je audytować. Bezpieczniejszy projekt oblicza zgodę raz na podstawie pochodzenia modelu oraz ustawienia operatora, a loader jedynie konsumuje decyzję.
Poprawka wprowadza XINFERENCE_TRUST_REMOTE_CODE, domyślnie wyłączone, i wspólną funkcję ustalającą zgodę. Wbudowane integracje mogą nadal działać na podstawie zaufanego pochodzenia (is_builtin), natomiast modele użytkownika wymagają jawnego opt-in operatora. To rozdziela wygodę kontrolowanego katalogu od ryzyka dowolnej ścieżki dostarczonej przez użytkownika.
„Launch model” staje się uprawnieniem do kodu
Organizacja może sądzić, że rola pozwalająca uruchamiać modele zużywa jedynie GPU i pamięć. Przy aktywnym remote code ta sama rola może wybrać kod wykonany przez worker. RBAC powinien więc traktować rejestrację niestandardowego modelu, wybór repozytorium oraz zmianę flagi zaufania jako działania administracyjne o skutku porównywalnym z wdrożeniem aplikacji.
W środowisku wielotenantowym wpływ zależy od izolacji. Worker może posiadać token Hugging Face, klucze storage’u, dostęp do innych modeli, wolumen cache i połączenia z usługami wewnętrznymi. Jeśli wiele tenantów współdzieli proces lub katalog, kod jednego użytkownika może odczytać zasoby drugiego. Oddzielny proces bez sekretów ogranicza część skutków; oddzielny sandbox lub węzeł z własną tożsamością ogranicza więcej.
Nie oznacza to, że każdy model Hugging Face jest złośliwy ani że standardowy plik wag automatycznie wykonuje kod. Ryzyko dotyczy ścieżek, które dopuszczają zdalną implementację i pochodzenia, którego operator nie zweryfikował. Należy odróżniać modele wbudowane, przypięte do zatwierdzonego commitu, od dowolnej nazwy lub ścieżki przekazanej przez użytkownika.
Aktualizacja i bezpieczna konfiguracja
Zaktualizuj Xinference do 2.12.0 lub nowszej wspieranej wersji. Po wdrożeniu sprawdź wersję koordynatora i wszystkich workerów; pozostawiony stary worker może nadal obsługiwać zadanie podatnym loaderem. Zrestartuj procesy w kontrolowany sposób i usuń stare obrazy z aktywnego harmonogramu, aby autoscaling nie przywrócił niepoprawnej wersji.
Pozostaw XINFERENCE_TRUST_REMOTE_CODE wyłączone, chyba że istnieje udokumentowana potrzeba. Jeżeli konkretny model naprawdę wymaga niestandardowej klasy, nie włączaj globalnego zaufania bez dodatkowych granic. Zweryfikuj właściciela repozytorium, przypnij niezmienny commit lub digest, przejrzyj kod, zapisz zatwierdzenie i uruchom model w osobnej puli workerów.
Lista dozwolonych modeli powinna wiązać logiczną nazwę z dokładnym źródłem, rewizją, sumą artefaktu i oczekiwanym loaderem. Sama nazwa organizacji w URL nie jest kontrolą integralności. Mirroruj zatwierdzone artefakty do własnego registry, podpisuj manifest i blokuj rozwiązywanie ruchomego main w produkcji.
Ograniczenie workera AI
Worker ładujący zewnętrzne modele powinien działać z minimalną tożsamością, bez poświadczeń panelu sterującego i bez sekretów innych tenantów. System plików może być tylko do odczytu poza kontrolowanym cache, a cache rozdzielony według domeny zaufania. Ogranicz capabilities kontenera, syscalle, dostęp do socketu runtime i możliwość montowania ścieżek hosta.
Egress powinien prowadzić tylko do zatwierdzonego mirroru i wymaganych usług. Jeżeli worker może łączyć się z metadanymi chmury, bazą, panelem Kubernetes i dowolnym Internetem, pojedynczy import otrzymuje szeroki zasięg. Używaj krótkotrwałych tożsamości workload zamiast stałych kluczy w zmiennych środowiskowych.
GPU nie tworzy automatycznie izolacji. Kod przygotowujący tokenizer i model wykonuje się na CPU w zwykłym procesie, zanim rozpocznie się inferencja. Kontenery także nie są pełną granicą między wrogimi tenantami bez poprawnego profilu, limitów, oddzielnych poświadczeń i aktualnego runtime. Dla modeli wymagających remote code warto przeznaczyć osobną pulę o zaostrzonym profilu.
Detekcja i przegląd historyczny
Zinwentaryzuj rejestracje niestandardowych modeli oraz wszystkie uruchomienia w okresie, gdy działała wersja wcześniejsza niż 2.12.0. Dla każdego zapisz użytkownika, czas, źródło, rewizję, rodzinę, worker i wynik autodetekcji. Priorytet mają nieznane repozytoria, ruchome rewizje, ścieżki prywatne kontrolowane przez użytkownika i modele, które pobrały dodatkowe pliki Python.
W logach workerów szukaj dynamicznych importów, pobierania plików .py, błędów klas z auto_map, nowych procesów potomnych, zmian w cache, odczytu zmiennych środowiskowych i nietypowych połączeń. Porównaj zawartość cache z zatwierdzonym commitem. Repozytorium mogło zmienić się od czasu uruchomienia, dlatego sama bieżąca wersja upstream nie dowodzi, co worker pobrał wcześniej.
Jeżeli potwierdzisz wykonanie niezatwierdzonego kodu, izoluj workera, zachowaj artefakty i telemetrię, a następnie odbuduj go. Rotuj poświadczenia, które proces mógł odczytać, i sprawdź systemy osiągalne przez jego tożsamość. Przejrzyj także inne zadania korzystające ze wspólnego cache lub obrazu.
Wnioski dla łańcucha dostaw AI
SBOM aplikacji nie obejmuje automatycznie kodu pobieranego przy ładowaniu modelu. Organizacja potrzebuje manifestu modelu zawierającego źródło, rewizję, format, niestandardowy kod, licencję i decyzję zaufania. Taki manifest powinien przechodzić przez ten sam proces promocji między dev, staging i produkcją co zależność programistyczna.
Rozdziel role: badacz może proponować model, zespół bezpieczeństwa lub platformy zatwierdza jego pochodzenie, a produkcyjny orchestrator uruchamia wyłącznie wersję z katalogu. Telemetria powinna pokazywać nie tylko model_name, ale też faktyczny commit i stan remote-code. Inaczej incydent responder nie odtworzy, jaki kod wykonał się w danym momencie.
Fakty źródłowe i wnioski Breachroad
Zakres przed 2.12.0, sześć loaderów, ścieżka auto_map, możliwość RCE oraz wyniki CVSS pochodzą z rekordu CVE i advisory VulnCheck. Domyślnie wyłączona zmienna, wyjątek dla wbudowanych modeli i wspólna funkcja polityki pochodzą z pull requestu projektu. Publiczne materiały użyte w artykule nie potwierdzają aktywnej eksploatacji.
Model uprawnień, izolacja workerów, manifest modelu, analiza cache i kolejność reagowania są wnioskami Breachroad. Szkolenia bezpieczeństwa AI dla organizacji pomagają zespołom bezpiecznie zarządzać modelami i agentami, a audyty aplikacji oraz API mogą zweryfikować RBAC, registry i granice wykonania platformy AI.
