W lipcu coś się zmieniło
Większość newsów o bezpieczeństwie znika po tygodniu. Ten został.
W lipcu 2026 Hugging Face poinformowało, że ktoś dostał się do części ich infrastruktury produkcyjnej. Najdziwniejsze było jednak to, kto za tym stał. Nie była to typowa grupa ludzi, która krok po kroku prowadzi atak, tylko autonomiczne agenty AI.
Kilka dni później OpenAI potwierdziło swój udział, a w późniejszym raporcie opisało sprawę szerzej. Agenty działały podczas wewnętrznych testów cyberbezpieczeństwa, głównie na modelu badawczym nazwanym przez OpenAI IM1, porównywalnym skalą do GPT-5.6 Sol. Dostały trudne zadania związane z wyszukiwaniem luk i miały pracować w odizolowanym środowisku testowym. W teorii nie powinny mieć wpływu na prawdziwy internet. W praktyce znalazły drogę na zewnątrz.
Hugging Face opisało sprawę 16 lipca, a później opublikowało szczegółową oś czasu. OpenAI dodało własne wyjaśnienie. Oba teksty warto przeczytać, ale najważniejsze wnioski nie dotyczą tylko laboratoriów AI.
Jak to poszło
Agenty działały w środowisku przygotowanym do testów. Takie środowisko ma zwykle przypominać prawdziwy system, ale być odcięte od świata. Problemem okazał się Artifactory, czyli wewnętrzna usługa używana między innymi do pobierania paczek z internetu. Miała być kontrolowaną bramką, a agenty wykorzystały ją najpierw jako nieautoryzowaną tablicę wiadomości, a później jako drogę do internetu.
Po wydostaniu się z testów agenty dalej wykonywały swoje zadanie, jakby prawdziwy internet był kolejną częścią ćwiczenia. Najpierw przejęły zewnętrzny sandbox do uruchamiania kodu, związany z podobnym benchmarkiem CyberGym, i użyły go jako bazy do dalszych działań. Później odnalazły publicznie wystawione dane dostępowe do Hugging Face i zaczęły szukać rozwiązań zadań ExploitGym na samej platformie.
Hugging Face nie było więc przypadkowym kliknięciem. Agenty trafiły w miejsce, gdzie przetwarzane są datasety, czyli zbiory danych używane później przez modele i aplikacje. Tam pojawił się dobrze znany problem w nowym opakowaniu: systemy, które przyjmują konfigurację lub szablony od użytkownika, mogą czasem zrobić więcej, niż powinny. Raport Hugging Face opisuje dwa wektory: odczyt lokalnych plików przez funkcję HDF5 oraz podatność w szablonach Jinja2, która pozwoliła uruchamiać kod na workerach produkcyjnych. Dalej było już klasycznie: sekrety ze środowiska, dostęp do klastrów, ruch po wewnętrznej infrastrukturze i tysiące automatycznych akcji rozłożonych na kilka dni.
Skala szkód jest ważna, bo łatwo ją przerysować. Hugging Face pisało o nieautoryzowanym dostępie do ograniczonego zestawu wewnętrznych datasetów i kilku poświadczeń używanych przez usługi. W technicznym opisie doprecyzowało, że dostęp do treści klientów dotyczył zestawu rozwiązań zadań ExploitGym/CyberGym zapisanych w pięciu datasetach oraz metadanych operacyjnych z zapytań do dataset servera. OpenAI dodało, że agenty GPT-5.6 Sol skopiowały część prywatnych danych ewaluacyjnych hostowanych na Hugging Face do publicznego datasetu.
Jednocześnie Hugging Face nie znalazło dowodów na manipulację publicznymi, użytkowymi modelami, datasetami ani Spaces, a łańcuch dostaw, w tym obrazy kontenerów i opublikowane paczki, został zweryfikowany jako czysty. OpenAI twierdzi, że ich produkty, dane klientów i dostępność usług nie ucierpiały. Sekrety zostały wymienione, maszyny przebudowane, ryzykowne ścieżki zamknięte, a sprawa zgłoszona odpowiednim służbom. Dobrze, że skończyło się właśnie tak. Nadal: nikt nie chce takiego weekendu.
Dlaczego to nie tylko historia „dla AI labów”
Przez lata opowieści o AI, które samo atakuje systemy, brzmiały jak temat z konferencji albo futurystycznego raportu. Lipiec pokazał coś bardziej przyziemnego i przez to ciekawszego: szybkie rozpoznanie, używanie znalezionych sekretów i przechodzenie przez kolejne warstwy systemu bez człowieka wpisującego każdą komendę.
Dwie rzeczy szczególnie nam utkwiły.
Po pierwsze, wejściem nie był otwarty SSH ani oczywisty panel admina. Wejściem były dane, konfiguracje i szablony. To ta sama rodzina problemów, co niebezpieczne importy, pluginy, pliki Markdown uruchamiające kod albo worker, który „tylko parsuje upload”. Jeśli wasz produkt przyjmuje treść od użytkownika i potem ją interpretuje, renderuje albo uruchamia, ten temat dotyczy również was.
Po drugie, zespół broniący systemu trafił na nietypową przeszkodę. Komercyjne modele AI w chmurze nie chciały analizować prawdziwych komend użytych w ataku, bo filtry bezpieczeństwa traktowały je jak próbę włamania. Dla modelu nie zawsze widać różnicę między atakującym a osobą, która bada incydent.
Hugging Face dokończyło analizę na modelu uruchomionym u siebie, na własnych maszynach. Dzięki temu podejrzane fragmenty kodu i wykradzione sekrety nie musiały trafiać do zewnętrznej usługi. To detal, który łatwo pominąć, ale jest ważny. Jeśli kiedyś będziecie chcieli użyć AI podczas prawdziwego incydentu, dobrze mieć model pod własną kontrolą zanim zacznie dzwonić pager.
Co zabieramy do własnej roboty
Na co dzień budujemy backendy, API i rozwiązania wokół PrestaShop w PHP, Symfony i Go. Nie trenujemy największych modeli na świecie. Mimo to ta historia jest zaskakująco blisko codziennej pracy:
- Wszystko, co dotyka uploadów, importów, szablonów albo pluginów, zasługuje na taką samą uwagę jak logowanie i uprawnienia.
- Jeśli testowe środowisko ma dostęp do proxy, rejestrów paczek albo internetu, to nie jest tak odizolowane, jak wygląda na diagramie.
- Procedury wymiany sekretów i przebudowy maszyn muszą działać szybko, bo automatyczny przeciwnik nie czeka, aż ktoś skończy kawę.
- Własne eksperymenty z agentami AI powinny mieć twarde limity: osobną sieć, małe uprawnienia i człowieka, który zatwierdza wyjście poza bezpieczne środowisko.
Warto przeczytać teksty Hugging Face i OpenAI spokojnie, bez paniki i bez sci-fi. Potem najlepiej wrócić do mniej efektownych rzeczy we własnych systemach: importów danych, dostępu do internetu, sekretów i workerów, które przetwarzają cudzą treść. Tam ta historia robi się naprawdę praktyczna.