Tag: NIST

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

Wprowadzenie do problemu / definicja

Rozwój modeli generatywnych coraz wyraźniej wpływa na obszar cyberbezpieczeństwa, wykraczając poza analizę kodu, wykrywanie błędów implementacyjnych czy automatyzację prostych zadań badawczych. Najnowszy przypadek pokazuje, że AI może wspierać również kryptanalizę, a więc identyfikowanie słabości w samych konstrukcjach kryptograficznych.

Opisane wyniki dotyczą dwóch odrębnych osiągnięć badawczych: skuteczniejszego ataku odzyskiwania klucza na HAWK-256, czyli testowy wariant kandydata do podpisów postkwantowych, oraz znaczącego przyspieszenia znanego ataku na zredukowaną, 7-rundową wersję AES-128. Choć nie oznacza to natychmiastowego zagrożenia dla powszechnie używanych systemów, publikacja ma duże znaczenie dla środowiska kryptograficznego i zespołów odpowiedzialnych za bezpieczeństwo długoterminowe.

W skrócie

• Model Claude miał pomóc w opracowaniu pełnego ataku odzyskiwania klucza dla HAWK-256.
• W ataku na HAWK wykorzystano wcześniej niewykorzystaną symetrię w strukturze kraty.
• Szacowany koszt ataku na HAWK-256 spadł z około 2^64 do około 2^38 operacji.
• Drugi wynik dotyczy nowej optymalizacji ataku meet-in-the-middle na 7-rundowy AES-128.
• Autorzy wskazują na przyspieszenie rzędu 200–800 razy względem wcześniejszego najlepszego podejścia.
• Nie ma obecnie podstaw, by uznać pełny AES-128 za naruszony lub niebezpieczny w produkcji.

Kontekst / historia

HAWK należy do grona schematów rozwijanych w ramach dodatkowego procesu standaryzacyjnego NIST dla podpisów postkwantowych. Bezpieczeństwo tej konstrukcji opiera się na problemach kratowych, które od lat są uznawane za jedną z najważniejszych rodzin mechanizmów odpornych na zagrożenia związane z przyszłymi komputerami kwantowymi.

W badaniach nad HAWK już wcześniej sugerowano, że odnalezienie odpowiedniej automorfii, czyli nietrywialnej symetrii zachowującej strukturę kraty, mogłoby znacząco ułatwić odzyskiwanie materiału tajnego. Przez długi czas nie było jednak jasne, czy taka właściwość może zostać praktycznie wykorzystana w tej konkretnej konstrukcji.

Równolegle środowisko kryptograficzne od lat analizuje także zredukowane wersje AES. Badanie szyfru z mniejszą liczbą rund nie oznacza złamania pełnej wersji algorytmu, ale pozwala mierzyć margines bezpieczeństwa i rozwijać nowe techniki kryptanalityczne. Z tego względu nawet wynik odnoszący się wyłącznie do 7-rundowego AES-128 jest ważnym sygnałem naukowym.

Analiza techniczna

W przypadku HAWK-256 badacze opisali atak odzyskiwania klucza oparty na wykorzystaniu dodatkowej automorfii w kracie HAWK. Taka symetria pozwala przekształcić problem do postaci łatwiejszej obliczeniowo, a następnie użyć technik redukcji krat i przesiewania do odnalezienia krótkich wektorów prowadzących do odtworzenia funkcjonalnie równoważnego materiału klucza tajnego.

To istotne rozróżnienie: opublikowany atak nie musi odzyskiwać pierwotnego ziarna klucza prywatnego. W praktyce wystarczy jednak uzyskać równoważny materiał podpisujący, który umożliwia generowanie poprawnych podpisów dla danego klucza publicznego. Z punktu widzenia bezpieczeństwa oznacza to skuteczne podważenie badanego wariantu schematu.

Według autorów koszt ataku dla HAWK-256 spadł z około 2^64 do około 2^38 operacji. To bardzo znaczące osłabienie parametru testowego, nawet jeśli atak nadal pozostaje wykładniczy. Jednocześnie publicznie udostępniona implementacja dotyczy wyłącznie HAWK-256, a nie większych wariantów HAWK-512 i HAWK-1024.

Drugi wynik dotyczy 7-rundowego AES-128 i rozwija wcześniejsze ataki typu meet-in-the-middle. Metoda ta polega na rozdzieleniu szyfru na etapy, obliczaniu stanów pośrednich z dwóch stron i dopasowywaniu ich przy użyciu tabel pomocniczych oraz odcisków pośrednich. Nowa konstrukcja, określana jako Möbius Bridge, ma umożliwiać usunięcie jednego z kosztownych etapów zgadywania 256 wartości.

Choć sama transformacja pozostaje kosztowna obliczeniowo, autorzy oceniają, że końcowy efekt daje przyspieszenie od 200 do 800 razy względem wcześniejszego najlepszego podejścia. Jednocześnie atak nadal wymaga około 2^105 wybranych tekstów jawnych szyfrowanych pod jednym nieznanym kluczem, co czyni go praktycznie nieosiągalnym poza warunkami czysto akademickimi.

Konsekwencje / ryzyko

Najważniejszy wniosek dla branży nie dotyczy natychmiastowego zagrożenia operacyjnego, lecz rosnącej roli AI w odkrywaniu słabości kryptograficznych. Dotychczas modele językowe kojarzono przede wszystkim z analizą kodu, automatyzacją exploit developmentu czy wsparciem inżynierii wstecznej. Ten przypadek pokazuje, że mogą być również użyteczne przy badaniu matematycznych fundamentów bezpieczeństwa.

Dla HAWK ryzyko ma przede wszystkim wymiar strategiczny. Jeśli wyniki zostaną niezależnie potwierdzone, mogą wpłynąć na ocenę bezpieczeństwa projektu, wymusić rewizję parametrów lub osłabić jego pozycję w procesie standaryzacji postkwantowej. Skuteczny atak na parametr testowy nie przesądza automatycznie o losie całej rodziny, ale stanowi wyraźny sygnał ostrzegawczy.

W przypadku AES praktyczne ryzyko pozostaje niskie. Badanie nie łamie pełnego, 10-rundowego AES-128 i nie wskazuje na konieczność natychmiastowych zmian w produkcyjnych wdrożeniach. Mimo to publikacja ma duże znaczenie badawcze, bo pokazuje, że AI może skracać czas potrzebny na opracowywanie nowych pomysłów kryptanalitycznych.

Rekomendacje

Organizacje nie powinny reagować panicznie, ale powinny potraktować te wyniki jako ważny sygnał dla strategii kryptograficznej i planów migracyjnych.

• Monitorować procesy standaryzacyjne NIST oraz status kandydatów postkwantowych.
• Budować kryptograficzną zwinność, aby możliwa była wymiana algorytmów, parametrów i długości kluczy bez kosztownej przebudowy systemów.
• Zakładać, że modele AI będą coraz skuteczniej wspierały analizę formalną i odkrywanie nietrywialnych zależności matematycznych.
• Zwiększać nacisk na niezależne audyty, walidację założeń bezpieczeństwa i testowanie implementacji.
• Nie wyciągać pochopnego wniosku, że AES-128 przestał być bezpieczny w zastosowaniach produkcyjnych.

Podsumowanie

Nowe badania wskazują, że AI zaczyna odgrywać coraz większą rolę nie tylko w analizie implementacji, ale również w przyspieszaniu właściwej kryptanalizy. Atak na HAWK-256 ujawnia realne osłabienie parametru testowego i może wpłynąć na dalszą ocenę tego schematu w procesie standaryzacji.

Z kolei przyspieszenie ataku na 7-rundowy AES-128 ma obecnie głównie wartość naukową, ale potwierdza, że modele AI mogą wspierać tworzenie nowych metod badawczych w kryptografii. Dla praktyków bezpieczeństwa kluczowy wniosek jest jasny: przyszła odporność algorytmów będzie zależeć nie tylko od klasycznych analiz akademickich, lecz także od tego, jak skutecznie środowisko nauczy się wykorzystywać i kontrolować narzędzia AI.

Źródła

1. https://www.anthropic.com/research/discovering-cryptographic-weaknesses
2. https://www.anthropic.com/document/hawk_key_recovery.pdf
3. https://www.anthropic.com/document/aes_mobius_bridge.pdf
4. https://csrc.nist.gov/projects/pqc-dig-sig/round-3-additional-signatures
5. https://thehackernews.com/2026/07/claude-ai-just-cracked-post-quantum.html