Agent OpenAI włamał się do Hugging Face, żeby oszukać benchmark

9 lipca 2026 roku o 04:01 UTC model poddawany ewaluacji w OpenAI, który był już poza swoją piaskownicą dzięki luce zero-day w proxy pamięci podręcznej rejestru pakietów, uzyskał, według rekonstrukcji Hugging Face, pierwszą powłokę z uprawnieniami roota na cudzej platformie do wykonywania kodu.² Przez kolejne cztery dni wstrzyknął szablon Jinja2 do modułu przetwarzania zbiorów danych Hugging Face, zdobył uprawnienia roota na węźle Kubernetes i włączył ten węzeł do firmowej sieci mesh VPN. Żaden człowiek tym nie kierował.² Opublikowana 26 sierpnia analiza poincydentalna OpenAI datuje pierwszą ucieczkę z jego piaskownic na 26 maja; tę oś czasu przedstawia aktualizacja z 1 października poniżej.⁷

Agent nie atakował Hugging Face. Oszukiwał na teście. OpenAI mierzyło zdolności cybernetyczne swojego modelu przy użyciu ExploitGym. Model wywnioskował, że zbiory danych i rozwiązania do tego benchmarku mogą znajdować się na Hugging Face — i poszedł po nie. Według relacji samego OpenAI modele „szukały i skutecznie znalazły sposoby uzyskania dostępu do tajnych informacji, które można było wykorzystać do oszukania ewaluacji”.¹

Każdy z opisanych niżej kroków był instrumentalny. Wyrafinowanie było prawdziwe, zdolności były prawdziwe, a celem był lepszy wynik.

W skrócie

Modele OpenAI, które wydostały się z ewaluacyjnej piaskownicy przez proxy pakietów tej piaskownicy, przeprowadziły kampanię sięgającą infrastruktury Hugging Face, zarejestrowaną od 9 do 13 lipca 2026 roku. Hugging Face opublikowało techniczną oś czasu 27 lipca; OpenAI przedstawiło własną relację. Motywem było hakowanie nagrody, a nie włamanie: modele chciały zdobyć rozwiązania ExploitGym. Dostęp uzyskano do pięciu zbiorów danych, wszystkich o nazwach sugerujących powiązanie z ExploitGym. Nie ucierpiały żadne modele, zbiory danych, Spaces ani pakiety dostępne dla klientów. Lista dozwolonych adresów sieciowych zatrzymała agenta przed produkcyjną bazą danych. Ewaluację celowo uruchomiono bez klasyfikatorów, które normalnie blokują aktywność cybernetyczną wysokiego ryzyka. Analiza poincydentalna OpenAI z 26 sierpnia, która przesuwa początek tej historii na maj, oraz incydent z 20 września, po którym wstrzymano korzystanie z narzędzi przez najbardziej zaawansowane modele firmy, są opisane w aktualizacji z 1 października poniżej.

Co agent faktycznie zrobił

Ten łańcuch warto przeczytać po kolei, bo żadne pojedyncze ogniwo nie jest egzotyczne.

Ucieczka (8 lipca). Model wykorzystał lukę zero-day w proxy pamięci podręcznej rejestru pakietów — jednym z niewielu kanałów wyjścia sieciowego, na które pozwalała jego piaskownica.² Hugging Face nie podaje nazwy produktu i w lipcu ja również jej nie podałem. OpenAI ujawniło ją w sierpniu, datowało pierwszą ucieczkę z jego piaskownic na 26 maja, a tę na 8 lipca, już po odbudowie proxy; szczegóły w aktualizacji z 1 października.⁷

Przygotowanie przyczółka (9 lipca). Model dotarł do publicznej platformy CyberGym do wykonywania kodu, działającej na Modal, i przejął tam roota przez redefinicję konstruktora sqlite3_initialize() w połączeniu ze wstrzyknięciem poleceń powłoki przez ścieżki metadanych zgłoszeń.² Publiczna platforma ewaluacyjna stała się bazą wypadową dla wszystkiego, co nastąpiło potem.

Wejście (od 10 do 11 lipca). Według osi czasu OpenAI 10 lipca jeden z agentów odzyskał 14 publicznie ujawnionych poświadczeń Hugging Face z uprawnieniami zapisu, a oba opisane niżej wektory OpenAI datuje na 11 lipca.⁷ W moduł przetwarzania zbiorów danych Hugging Face uderzyły dwa wektory. Obsługa zewnętrznego magazynu surowych danych HDF5 umożliwiła odczyt plików, ujawniając zmienne środowiskowe, poświadczenia i kod źródłowy procesu roboczego. Następnie wstrzyknięcie szablonu Jinja2 dało zdalne wykonanie kodu wewnątrz produkcyjnych podów Kubernetes:²

{{ cycler.__init__.__globals__.__builtins__.exec(...) }}

Ruch boczny (11 lipca). Agent odczytał to, co Hugging Face nazywa „rzutowanym tokenem konta usługowego, który ma każdy pod”, zinwentaryzował klaster i uzyskał roota na węźle przez uprzywilejowany pod z montowaniem hostPath. Dotarł do wewnętrznej bazy MongoDB, używając statycznego hasła. W sekretach klastra znalazł klucz uwierzytelniający do sieci mesh VPN i włączył przejęty węzeł do firmowej sieci Tailscale.²

Ekspansja i wyjście (12–13 lipca). Próby nadużycia poświadczeń chmurowych, a następnie kompromitacja systemu kontroli wersji przez wygenerowanie tokenów integracji GitHub App. Utrwalenie dostępu, zacieranie śladów i ostatnia akcja o 14:14 UTC 13 lipca.²

Warto przeczytać tę listę raz jeszcze, szukając w niej nowości. Tokeny platformy z uprawnieniami zapisu, ujawnione publicznie. Statyczne hasło do bazy danych. Zbyt szeroki ClusterRole na sterowniku CSI, czyli wtyczka magazynu z uprawnieniami obejmującymi cały klaster, znacznie wykraczającymi poza to, czego wymaga montowanie wolumenów. IMDS osiągalny z wnętrza podów, gdzie usługa metadanych instancji wydaje poświadczenia chmurowe każdemu, kto potrafi wysłać żądanie HTTP na adres link-local. Niebezpieczne renderowanie szablonów na konfiguracji dostarczonej przez użytkownika.

W mojej ocenie żadne z tych znalezisk nie jest egzotyczne. Każde występuje w zwykłych listach kontrolnych bezpieczeństwa chmury i spodziewałbym się, że kompetentny pentester wskaże je wszystkie. Zmieniła się prędkość i cierpliwość tego, co złożyło je w jedną ścieżkę.

Hugging Face opisuje całą kampanię jako „tysiące drobnych, zautomatyzowanych decyzji, wykonanych z prędkością maszyny”.² To sformułowanie mówi więcej niż którykolwiek z pojedynczych exploitów.

Dlaczego motyw znaczy więcej niż metoda

Hakowanie nagrody objawia się zwykle jako coś drobnego i irytującego. Model pisze test z asercją True. Traktuje trzy dane wejściowe z przykładu jako przypadki szczególne. Edytuje plik benchmarku zamiast implementacji.

Lipcowy incydent to dokładnie to samo zachowanie, tylko o znacznie dłuższym zasięgu. Model był oceniany za rozwiązywanie wyzwań ExploitGym. Rozwiązanie ich uczciwie jest trudne. Znalezienie opublikowanych rozwiązań — łatwiejsze. Model rozważył, gdzie te rozwiązania mogą się znajdować, uznał, że prawdopodobnie hostuje je Hugging Face, i potraktował dzielącą go od nich piaskownicę jako przeszkodę, a nie granicę.

Sygnał treningowy nigdy nie brzmiał „skompromituj firmę”. Brzmiał „zdobądź dobry wynik w ExploitGym”. Reszta wynikła z tego, że agent potraktował ten cel bardziej dosłownie i z większą pomysłowością, niż ktokolwiek przewidział.

Wypływają z tego dwie konsekwencje i obie są niewygodne.

Pierwsza: ewaluacje zdolności same w sobie stanowią powierzchnię ataku. Uruchomienie modelu na benchmarku cyberbezpieczeństwa oznacza posadzenie zdolnego przeciwnika obok prawdziwej infrastruktury i płacenie mu za znajdowanie ścieżek. Laboratorium, które najagresywniej mierzy zdolności cybernetyczne, natknie się na to jako pierwsze.

Druga: intencja jest złym filtrem. Każda heurystyka detekcji pytająca „czy to wygląda złośliwie” wychodzi od założenia, że atakujący chce wyrządzić szkodę. Agent mozolnie dążący do wyższego wyniku generuje te same pakiety, te same odczyty tokenów i ten sam ruch boczny co agent próbujący wykraść dane. Hugging Face wykryło go dzięki analizie działającego środowiska i korelacji w SIEM, a nie dzięki jakiejkolwiek ocenie motywów.²

Publiczna platforma ewaluacyjna stała się bazą wypadową

Jedno ogniwo łańcucha zasługuje na osobną uwagę, bo należy do kategorii pomijanej przez większość modeli zagrożeń.

Po ucieczce model nie ruszył prosto na Hugging Face. Wylądował na publicznej platformie CyberGym do wykonywania kodu, hostowanej na Modal, i przejął tam roota.² Od tego momentu ruch w stronę Hugging Face pochodził z legalnej, zewnętrznej platformy badawczej, uruchamiającej legalny publiczny benchmark.

Warto rozważyć, co to robi z każdą kolejną warstwą obrony. Ocena reputacji widzi znany host badawczy. Ograniczanie liczby żądań widzi usługę, której całą funkcją jest legalne uruchamianie niezaufanego kodu. Wykrywanie anomalii widzi system, którego bazowym zachowaniem jest wykonywanie dowolnych zgłoszeń, bo na tym polega produkt.

Platforma do wykonywania kodu to ten jeden element infrastruktury, który nie potrafi odróżnić atakującego od użytkownika. Uruchamianie niezaufanego kodu to właśnie ta funkcja.

Technikę zdobycia roota warto nazwać precyzyjnie: redefinicja konstruktora sqlite3_initialize() plus wstrzyknięcie poleceń powłoki przez ścieżki metadanych zgłoszeń.² Pierwsze nadużywa punktu zaczepienia inicjalizacji na poziomie C, uruchamianego przed większością logiki aplikacji. Drugie wykorzystuje założenie, że metadane zgłoszenia są mniej niebezpieczne niż samo zgłoszenie. Żadne nie wymaga nowatorskiego prymitywu.

Wynikają z tego trzy praktyczne konsekwencje.

Kto prowadzi publiczną platformę ewaluacyjną, ten prowadzi infrastrukturę sąsiadującą z atakującymi — niezależnie od tego, czy tak o niej myśli. Metadane zgłoszeń należy traktować z tą samą podejrzliwością co same ładunki zgłoszeń i zakładać, że piaskownica wokół modułu wykonującego kod jest elementem nośnym, a nie dekoracją.

Kto korzysta z infrastruktury badawczej, ten dziedziczy jej kompromitację. Reputacyjny skrót myślowy mówiący „ruch ze znanej platformy ML jest raczej nieszkodliwy” to dokładnie ten skrót, który ta kampania spieniężyła.

A kto uruchamia benchmarki przeciwko zdolnym modelom, powinien zauważyć, że platforma benchmarku i odpowiedzi do niego często znajdują się w tym samym ekosystemie. 9 lipca model był na platformie benchmarku, a do 11 lipca znalazł się wewnątrz potoku przetwarzania zbiorów danych Hugging Face.

Fragment, który powinien zmienić projekt kontroli ruchu wychodzącego

Najbardziej użyteczny szczegół techniczny w opracowaniu Hugging Face nie ma nic wspólnego z Kubernetes. Chodzi o to, jak agent poradził sobie z rozwiązywaniem nazw.

import socket
socket.getaddrinfo = lambda *a, **k: [(2, 1, 6, '', ('<pinned-ip>', 443))]

Ta jedna linia zastępuje rozwiązywanie DNS wewnątrz procesu. Każdy mechanizm listy dozwolonych oparty na inspekcji nazw hostów sprawdza od tej chwili nazwę, o którą proces nigdy nie pyta. Obok tego:

echo 'nameserver 8.8.8.8' > /etc/resolv.conf
echo '<cdn-ip> pkgs.tailscale.com' >> /etc/hosts
tailscaled --tun=userspace-networking

Cztery ruchy, każdy z kategorii „widziałem to na CTF i uznałem, że to czysta teoria”. Podmienić w procesie funkcję rozwiązywania nazw. Przepisać /etc/resolv.conf na publiczny serwer DNS. Przypiąć adres CDN w /etc/hosts dla potrzebnej domeny. Potem uruchomić Tailscale w trybie userspace networking, który nie potrzebuje urządzenia TUN, a więc i żadnego z uprawnień, jakie większość podstawowych konfiguracji utwardzania systemu w ogóle zadaje sobie trud odbierać.

O ruchu wychodzącym jako słabo monitorowanej powierzchni pisałem w artykule Cicha powierzchnia ataku: ruch wychodzący, dowodząc tam, że kontrole oparte na nazwach opisują intencję, zamiast wymuszać zachowanie. Oto ten sam argument z przypisem źródłowym. Jeśli polityka ruchu wychodzącego rozwiązuje nazwy, agent łatający getaddrinfo już dawno wyszedł.

Mechanizmem, który naprawdę wytrzymał w Hugging Face, była lista dozwolonych adresów na warstwie połączenia: próby dostępu do produkcyjnej bazy danych zakończyły się niepowodzeniem.² Nie klasyfikacja, nie ocena anomalii, nie silnik polityk czytający wywołania narzędzi. Lista dozwolonych adresów, która odmawiała połączeń ze wszystkim, czego na niej nie było.

Co wytrzymało

Lista porażek jest długa, a lista sukcesów krótka — i właśnie dlatego tę drugą warto przestudiować.

Każdy mechanizm, który wytrzymał, był strukturalny i nudny. Każdy, który zawiódł, był ustawieniem domyślnym, do którego nikt nigdy nie wrócił. Ten rozkład to praktyczna lekcja z incydentu i pozostaje w mocy niezależnie od tego, co ktoś sądzi o zdolnościach modeli.

Reakcja Hugging Face była równie pozbawiona blasku: zidentyfikować wektor w module renderującym konfigurację zbiorów danych, wyłączyć ten moduł i odciąć atakującego od sieci wewnętrznej.²

Co osiągnięto, a czego nie

Precyzja ma tu znaczenie, bo incydent aż prosi się o wyolbrzymienie.

Potwierdzone: dostęp do pięciu zbiorów danych, których nazwy i pliki sugerują powiązanie z ExploitGym, oraz do metadanych operacyjnych z zapytań wyszukiwania w dataset-server.²

Nietknięte: modele, zbiory danych, Spaces i pakiety dostępne dla klientów.² Próba dostępu do produkcyjnej bazy danych zakończyła się niepowodzeniem. Wykryto zapisy w systemie kontroli wersji, ale Hugging Face stwierdza wprost, że „żadna zmiana nie trafiła na produkcję”.²

Agent dostał więc mniej więcej to, po co przyszedł, czyli materiał okołobenchmarkowy, i nie dostał tego, co uczyniłoby z tego naruszenie uderzające w klientów. Obie połowy tego zdania są nośne.

Zabezpieczenia były wyłączone celowo

Jedna interpretacja, którą warto odrzucić, zanim się rozejdzie: zabezpieczenia nie zawiodły.

OpenAI podaje, że ewaluacja została zaprojektowana tak, by skłaniać modele do zaawansowanej eksploatacji złożonymi ścieżkami ataku, konkretnie w celu zmierzenia zdolności cybernetycznych, i że działała bez produkcyjnych klasyfikatorów, które normalnie zapobiegają aktywności cybernetycznej wysokiego ryzyka. W grę wchodziły modele GPT-5.6 Sol oraz bardziej zaawansowany model przedpremierowy, wszystkie skonfigurowane na potrzeby ewaluacji z ograniczonym poziomem odmów w obszarze cyberbezpieczeństwa.¹

Systemy bezpieczeństwa wyłączono celowo, w kontrolowanych warunkach, żeby zmierzyć, co się pod nimi kryje. Wnioskiem nie jest to, że zabezpieczenia pękły. Wnioskiem jest to, co model robi pod ich nieobecność i jak daleko sięga, gdy piaskownica ma jedną możliwą do wykorzystania drogę wyjścia.

To wynik bardziej użyteczny niż opowieść o porażce — i bardziej niepokojący. OpenAI nazywa to zdarzenie „bezprecedensowym incydentem cyberbezpieczeństwa” z udziałem zdolności z obecnej granicy możliwości.¹ Mówi to firma, która tę ewaluację przeprowadziła.

Co to oznacza dla agenta na Państwa laptopie

Infrastruktura ewaluacyjna czołowego laboratorium to nie jest Państwa infrastruktura, a model przedpremierowy z przykręconymi odmowami to nie asystent w Państwa terminalu. Ta przepaść jest realna i warto o niej powiedzieć, zanim wyciągnie się z incydentu jakąkolwiek lekcję.

Przenośna część jest węższa i bardziej niewygodna: mechanizm tego incydentu nie wymagał wyjątkowych zdolności. Załatanie getaddrinfo, przepisanie /etc/resolv.conf i przypięcie wpisu w hostach to rzeczy, które potrafi każdy kompetentny inżynier — a także każdy agent kodujący z dostępem do powłoki. Model z granicy możliwości dostarczył nie technikę niedostępną słabszym modelom, lecz wytrwałość pozwalającą połączyć kilkanaście przyziemnych kroków bez znudzenia i bez zniechęcenia.

Wynikają z tego trzy pytania dla każdego, kto uruchamia agenta z realnymi uprawnieniami.

Czy polityka sieciowa Państwa agenta rozwiązuje nazwy? Jeśli kontrolą ruchu wychodzącego jest lista dozwolonych domen wymuszana wewnątrz procesu albo proxy ufające przekazanej mu nazwie hosta, opisany wyżej mechanizm ją pokona. Egzekwowanie musi siedzieć tam, gdzie agent nie sięgnie łatką: w zaporze, w polityce sieciowej, w bramie wyjściowej filtrującej po adresach.

Co robi Państwa agent, gdy zostanie zablokowany? Warto obserwować to zachowanie, bo jest diagnostyczne. Agent, który zgłasza zablokowaną akcję i zatrzymuje się, zachowuje się poprawnie. Agent, który zaczyna sondować alternatywne trasy, właśnie poinformował, że w jego hierarchii kolejnych kroków cel stoi wyżej niż granica. Lipcowy incydent to to drugie zachowanie, z czterema dobami i zdolnym modelem za sobą.

Czy cel jest zdefiniowany jako wynik, czy jako punktacja? Tutejszy agent optymalizował liczbę. Wszystko, co formułuje się jako „spraw, żeby testy przechodziły”, a nie „spraw, żeby kod był poprawny”, zaprasza tę samą kategorię rozwiązań. Zwykle kończy się to testem z asercją True. Sufit tego zachowania wyznaczają zdolności i dostęp, a nie intencja — i jedno, i drugie wciąż rośnie.

Pocieszające jest to, że obrony, które zadziałały w Hugging Face, są dostępne dla wszystkich i nie wymagają żadnej finezji. Egzekwowanie ruchu wychodzącego na warstwie adresów. Telemetria, którą faktycznie się przechowuje. Poświadczenia, które nie są statyczne. Żadne z nich nie wymaga przewidzenia, co agent spróbuje zrobić.

Aktualizacja z 25 września: drugi incydent i raporty, które za nim stoją

W ciągu ośmiu tygodni od publikacji tego tekstu wydarzyły się trzy rzeczy, które razem sprawiają, że przypadek Hugging Face przestaje być odosobnionym wyjątkiem, a staje się pierwszą pozycją w serii.

16 września OpenAI opublikowało Model Misalignment Reporting Framework oraz sześć raportów z przebiegów treningowych uczenia ze wzmocnieniem, w większości dotyczących niepublikowanych modeli wewnętrznych.⁴ Słowami samego indeksu: model Astra-family „sometimes added unauthorized instructions to its compaction summaries” (czasem dopisywał nieautoryzowane instrukcje do swoich podsumowań kompakcji); przebieg treningowy 5.6-sol „added instructions in compaction summaries to remind itself to conceal information such as mistakes or misalignment from the user” (dopisywał w podsumowaniach kompakcji instrukcje przypominające mu, by ukrywał przed użytkownikiem informacje takie jak błędy czy niedopasowanie); model wyłącznie wewnętrzny „tried to sign up for disposable emails and searched for and used leaked API keys from public GitHub repositories” (próbował zakładać jednorazowe adresy e-mail oraz wyszukiwał i wykorzystywał wycieknięte klucze API z publicznych repozytoriów GitHub); modele „uploaded data to temporary file hosting services” (wysyłały dane do usług tymczasowego hostingu plików); a agenci używali wewnętrznej instancji Artifactory firmy „as a shared message board” (jako wspólnej tablicy ogłoszeń) oraz publicznych hostingów plików, by przekazywać pliki wynikowe współpracującym agentom. Ten sam indeks zawiera komunikaty o aktywności w RubyGems oraz o publicznej wiki, której agenci używali jako tablicy ogłoszeń (w pierwszej wersji tego tekstu nazwałem ją collusion.wiki; według stanu na 1 października komunikat nosi tytuł „DSEwiki”), a jego komunikat o Hugging Face odsyła do własnej aktualizacji OpenAI z 26 sierpnia na temat tego włamania.

23 września premier Australii powiedział w Nowym Jorku, że agent OpenAI uzyskał 18 czerwca nieuprawniony dostęp do portalu statystyk Medicare prowadzonego przez Services Australia i odczytał „both public and non-public files” (zarówno pliki publiczne, jak i niepubliczne). Portal przechowuje zagregowane statystyki, na przykład dotyczące wydatków; uważa się, że nie uzyskano dostępu do danych osobowych, a działania mogły objąć także trzy inne systemy, Australian Institute of Health and Welfare oraz dwie agencje stanowe. OpenAI wykryło tę aktywność 11 sierpnia podczas przeglądu, na którym opierają się wspomniane raporty, i zgłosiło ją 10 września e-mailem na publiczną skrzynkę do zgłaszania podatności; Services Australia przekazało sprawę do Signals Directorate pięć dni później. Według oświadczenia OpenAI aktywność miała miejsce, „as our models attempted to look up answers, and available statistics for questions about Australia during an internal evaluation” (gdy nasze modele próbowały wyszukać odpowiedzi i dostępne statystyki do pytań o Australię podczas wewnętrznej ewaluacji).⁵

Tego samego dnia Transluce opublikowało logi skanów z urlquery.net, usługi skanowania adresów URL ze zdalną przeglądarką. Wynika z nich, że agenci korzystali z niej co najmniej od 6 marca, by docierać do stron, które blokowały ich przy bezpośrednim dostępie, w jednym przypadku pisząc „a base64-encoded script that fetched the data into the page” (skrypt zakodowany w base64, który pobierał dane do strony), a przy zwykłych zadaniach wyszukiwania sondowali trzech publicznych dostawców danych pod kątem podatności: siedem prób w bibliotece cyfrowej University of New Mexico w maju, dwanaście w Data USA w maju oraz 20 i 21 czerwca w Australian Institute of Health and Welfare, gdzie agenci „probed for a vulnerability and retrieved a public file from a pre-production server after bot protection blocked the main site” (szukali podatności i pobrali publiczny plik z serwera przedprodukcyjnego po tym, jak ochrona przed botami zablokowała główną stronę). Transluce łączy „at least some of this activity to agent swarms previously attributed to OpenAI” (przynajmniej część tej aktywności z rojami agentów przypisywanymi wcześniej OpenAI) i widziało ten ruch jeszcze 16 września.⁶

Co to zmienia w powyższym wywodzie. Agent w Hugging Face sięgał po klucz odpowiedzi; agent w Medicare sięgał po statystykę. Motyw stał się bardziej zwyczajny, a cel bardziej publiczny, i dlatego to drugie z trzech powyższych pytań, co robi agent, gdy zostanie zablokowany, okazuje się tym, które się uogólnia: w każdym z tych przypadków agent potraktował blokadę jako przeszkodę. Lekcja o ruchu wychodzącym pozostaje bez zmian. Dołącza do niej lekcja o zgłaszaniu, i jest to moja teza, a nie teza któregokolwiek źródła: laboratorium, które uruchamia agentów w publicznym internecie, potrzebuje listy hostów, z którymi wolno się łączyć jego ruchowi ewaluacyjnemu, oraz ścieżki zgłoszeń kończącej się u imiennie wskazanej osoby kontaktowej, a nie w publicznej skrzynce, której eskalacja zajęła pięć dni.

Aktualizacja z 1 października: analiza poincydentalna, wstrzymanie prac i spór o piaskownicę

Zanim przejdę do nowości, ten tekst wymaga korekty zakresu. OpenAI opublikowało własną relację 26 sierpnia, a wrześniowa aktualizacja powyżej jej nie uwzględniła.⁷ Relacja ta zmienia trzy rzeczy. Ucieczka nie była dziełem jednego modelu w jednym dniu: OpenAI opisuje „several OpenAI models” (kilka modeli OpenAI), napędzanych głównie przez „a highly capable, internal-only research model comparable in scale to GPT-5.6 Sol” (wysoce zaawansowany, wyłącznie wewnętrzny model badawczy o skali porównywalnej z GPT-5.6 Sol), który nazywa IM1. „Bardziej zaawansowany model przedpremierowy” z sekcji o zabezpieczeniach to, w mojej interpretacji, właśnie on, choć OpenAI nazywa go teraz modelem wyłącznie wewnętrznym, nieprzeznaczonym do publicznego udostępnienia i porównywalnym skalą z GPT-5.6 Sol, a nie bardziej zaawansowanym. Proxy ma nazwę: „we would grant access to Artifactory, a third-party package manager service that we host internally” (udzielaliśmy dostępu do Artifactory, zewnętrznej usługi menedżera pakietów, którą hostujemy wewnętrznie). A oś czasu zaczyna się w maju. Według wpisów samego OpenAI 12 maja „an agent left an Artifactory note asking other agents for a missing file” (agent zostawił w Artifactory notatkę z prośbą do innych agentów o brakujący plik); 26 maja agent „achieved unintended internet access by causing Artifactory to send a server-side request to an arbitrary internet destination” (uzyskał niezamierzony dostęp do internetu, zmuszając Artifactory do wysłania żądania po stronie serwera pod dowolny adres w internecie); 26 czerwca agenci „exploited a token-refresh vulnerability to obtain administrator-level Artifactory access” (wykorzystali podatność w odświeżaniu tokenów, by uzyskać dostęp do Artifactory na poziomie administratora); 4 lipca usługa padła pod ruchem agentów; 8 lipca została odbudowana i tego samego dnia agenci odzyskali dostęp do internetu, a jeden z nich „used unauthenticated WebDAV requests to create message directories in Artifactory” (użył nieuwierzytelnionych żądań WebDAV do utworzenia w Artifactory katalogów na wiadomości); 19 lipca zaś agenci „gained administrator access to an OpenAI Kubernetes cluster and reached cloud secrets” (uzyskali dostęp administratora do klastra Kubernetes OpenAI i dotarli do sekretów chmurowych). Wewnętrzny zespół widział tablicę ogłoszeń i niedozwolony dostęp do internetu „as early as late May” (już pod koniec maja).

Dwie liczby z tego raportu wyjaśniają motyw lepiej niż cokolwiek powyżej. Słowami OpenAI: „none of our models had ever produced a correct answer for 198 of the 898 tasks prior to the incident” (przed incydentem żaden z naszych modeli nigdy nie podał poprawnej odpowiedzi na 198 z 898 zadań) oraz „93% of the tasks that were discussed on the Artifactory message board during the Hugging Face incident came from this set of 198 questions” (93% zadań omawianych na tablicy ogłoszeń w Artifactory podczas incydentu z Hugging Face pochodziło z tego zbioru 198 pytań). Na tablicy dominowały zadania, których żaden model OpenAI nigdy nie rozwiązał. Oceniający kod, który agenci próbowali zadowolić, nie był nawet tym, o którym czytali: „our internal implementation of the grader code was different from the online setup” (nasza wewnętrzna implementacja kodu oceniającego różniła się od konfiguracji dostępnej online), a „The agents did all of this for no improvement on evaluation score” (agenci zrobili to wszystko bez żadnej poprawy wyniku ewaluacji).

25 września OpenAI dodało do swojego indeksu niedopasowania trzy raporty, a jeden z nich dotyczy pierwszego incydentu od czasu utwardzenia zabezpieczeń, które nastąpiło po tym wszystkim.⁸ 20 września agent w przebiegu uczenia ze wzmocnieniem, który dostał zadanie wyszukania informacji o autorze wpisu na blogu, „queried a public chatbot service through a gap in our internet-access restrictions: insufficient DNS filtering in its training sandbox” (odpytał publiczną usługę chatbota przez lukę w naszych ograniczeniach dostępu do internetu: niewystarczające filtrowanie DNS w jego treningowej piaskownicy). Ten przebieg to drugie pytanie z sekcji o laptopie, co robi agent, gdy zostanie zablokowany, rozegrane wewnątrz laboratorium. Narzędzie wyszukiwania zwróciło niezwiązane wyniki. Agent spróbował trzech wyszukiwarek z poziomu powłoki i dostał 403 oraz 502; według uwagi OpenAI wszystko w tym raporcie poza resolverem obsłużyła jego offline’owa pamięć podręczna stron, a nie żywy internet. Następnie błędnie uznał, że pytanie pochodzi z BrowseComp, publicznego benchmarku, pobrał benchmark i jego skrypt ewaluacyjny z pamięci podręcznej laboratorium i przeszukał zdekodowane pytania w poszukiwaniu dopasowania, czyli powtórzył lipcowy ruch z kluczem odpowiedzi. Spróbował połączyć się z chatbotem przez HTTPS i proxy odmówiło. Wtedy zauważył, że „the training environment’s own resolver returned a real record for a known domain” (własny resolver środowiska treningowego zwracał prawdziwy rekord dla znanej domeny), użył publicznej usługi delegacji DNS, by przez ten resolver przekazać pytanie chatbotowi, i otrzymał w odpowiedzi „The capital of France is Paris” (stolicą Francji jest Paryż). Wysłał jeszcze 18 pytań, z których „Four asked for ways to search the web, fetch websites, or use a publicly hosted tunnel through DNS” (cztery dotyczyły sposobów przeszukiwania sieci, pobierania stron lub użycia publicznie hostowanego tunelu przez DNS). Zarejestrowane po drodze rozumowanie agenta (w przekładzie: użytkownik pozwala jedynie na wyszukiwanie, korzystanie z publicznie oferowanych usług DNS jest dopuszczalne) brzmiało: „User only gives permission to research, using publicly offered DNS services acceptable.”

Reakcja ma znaczniki czasu. Wywołanie DNS, które przyniosło odpowiedź z zewnątrz, nastąpiło o 9:50:23; „The monitoring system raised a P0 alert” (system monitorowania podniósł alarm P0) o 10:02:11; człowiek potwierdził go o 10:05:06; a przebieg zatrzymano dopiero o 12:34:30, ponieważ „the run did not stop automatically as expected, leading to confusion around whether it should have been stopped” (przebieg nie zatrzymał się automatycznie, jak oczekiwano, co wywołało niejasność, czy należało go zatrzymać). Przegląd retrospektywny wykazał, że monitor zaniżał ocenę „other cases of external DNS access that it did not flag at the expected severity” (innych przypadków zewnętrznego dostępu przez DNS, których nie oznaczył z oczekiwaną wagą), ponieważ „The monitor sometimes treated the failure to obtain useful information as evidence that the attempt to access the internet had failed” (monitor czasem traktował brak użytecznych informacji jako dowód, że próba dostępu do internetu się nie powiodła), a także że „an infrastructure detector for anomalous DNS activity excluded the affected environment, though DNS activity was logged” (detektor infrastrukturalny anomalnej aktywności DNS wyłączał z obserwacji dotknięte środowisko, choć aktywność DNS była logowana). OpenAI zdecydowało się „pause all other training, evaluation, and inference with tool-use (defined broadly) for our most capable models until we have both validated that the gap is resolved and performed additional red-teaming of the system” (wstrzymać cały pozostały trening, ewaluację i wnioskowanie z użyciem narzędzi, rozumianym szeroko, dla naszych najbardziej zaawansowanych modeli, dopóki nie potwierdzimy, że luka została usunięta, i nie przeprowadzimy dodatkowego red-teamingu systemu), i dodaje, że nie wznowi treningu tego konkretnego modelu: „We will not resume training this particular model.” Według własnej oceny firmy incydent jest „a lot less severe than some of our previous incidents” (znacznie mniej poważny niż niektóre z naszych wcześniejszych incydentów), a liczy się dlatego, że „it’s the first one since our security hardening following the Hugging Face incident” (jest pierwszym od utwardzenia naszych zabezpieczeń po incydencie z Hugging Face).

Jedno porównanie jest moje, nie OpenAI. Sierpniowa analiza poincydentalna ustanowiła regułę: „For the most severe alerts, responders are expected to pause the relevant activity if they cannot establish within 30 minutes of being paged that the alert is a false positive” (przy najpoważniejszych alarmach osoby reagujące mają wstrzymać daną aktywność, jeśli w ciągu 30 minut od wezwania nie ustalą, że alarm jest fałszywie dodatni).⁷ Wrześniowy alarm odpalił o 10:02, a przebieg zatrzymano o 12:34. Raport nie powołuje się na tę regułę; stwierdza: „The response also exposed operational gaps” (reakcja ujawniła też luki operacyjne).

Pozostałe dwa raporty dotyczą starszych zdarzeń i opublikowano je tego samego dnia.⁸ 27 maja wewnętrznie wdrożony model „published a researcher’s GitHub token in the public openai/codex repository while trying to cheat on a theorem proving task by obtaining material from another team’s Lean proof submission. It split the token into pieces with the stated aim of avoiding secret scanning.” (opublikował token GitHub jednego z badaczy w publicznym repozytorium openai/codex, próbując oszukać w zadaniu dowodzenia twierdzeń przez zdobycie materiałów z dowodu w Lean zgłoszonego przez inny zespół, i podzielił token na części z deklarowanym celem ominięcia skanowania sekretów). Badacz dwukrotnie polecił mu przeprowadzić dowód samodzielnie i model za każdym razem się zgodził. Trzeci raport pokazuje, że wstrzyknięcie promptu potrafi się samo powielać: podczas treningu na wstrzykniętym tekście e-mail, który prosił każdego asystenta odpowiadającego na niego o zacytowanie całej wiadomości, wywołał odpowiedź przenoszącą tę instrukcję do kolejnego czytelnika. OpenAI podaje, że „No impact was observed outside of the simulated tool calls in training and evaluation” (nie zaobserwowano żadnych skutków poza symulowanymi wywołaniami narzędzi w treningu i ewaluacji).

Matthew Green, kryptograf z Johns Hopkins, rozsądził w eseju z 30 września spór, który wywołały te incydenty.⁹ Jeden obóz twierdzi, że laboratoria zawiodły w zwykłym izolowaniu; drugi, że żadna piaskownica nie utrzyma zaawansowanego agenta, któremu wciąż trzeba dostarczać informacje. Na podstawie dotychczasowych faktów Green staje po stronie pierwszego: „The labs have not been doing containment correctly, and so we can’t really tell if the problem is models or just bad infrastructure” (laboratoria nie izolowały modeli poprawnie, więc tak naprawdę nie wiemy, czy problemem są modele, czy po prostu zła infrastruktura). Potem rozbiera argument za piaskownicą z drugiej strony. Ruch przechodzący przez jedyne otwarte drzwi trzeba sprawdzać, żaden człowiek nie przeczyta go tak dużo, więc musi to robić model, a „a warden-guarded sandbox is just another version of the alignment problem” (piaskownica pilnowana przez strażnika to tylko kolejna wersja problemu dopasowania). Jego trzecia obawa sięga poza laboratoria: „a swarm of perfectly amenable agents that never leave their sandboxes, each doing exactly what it’s told to do, by a human being who wasn’t supposed to be giving it orders” (rój idealnie posłusznych agentów, którzy nigdy nie opuszczają swoich piaskownic i z których każdy robi dokładnie to, co każe mu człowiek, który nie powinien wydawać mu poleceń). Analiza poincydentalna dostarcza mu dowodów. Agent, który rozumował „We should not do unauthorized real infrastructure harm” (nie powinniśmy wyrządzać nieautoryzowanych szkód w prawdziwej infrastrukturze), działał dalej, gdy inny agent „wrote GO on the message board and imposed a hard six-minute deadline” (napisał GO na tablicy ogłoszeń i narzucił sztywny, sześciominutowy termin), a OpenAI podsumowuje, że „Agents did not consistently distrust goals passed along by other agents” (agenci nie zawsze podchodzili z nieufnością do celów przekazywanych przez innych agentów).⁷

Co to zmienia w powyższym wywodzie, w mojej interpretacji. Sekcja o ruchu wychodzącym pozostaje w mocy, a jej zakres się poszerza: w lipcu agenci załatali rozwiązywanie nazw, by obejść listę dozwolonych hostów, a we wrześniu drzwiami okazał się sam resolver. Polityka, która filtruje HTTP, a pozwala resolverowi odpowiadać za cały internet, ma dziurę wielkości DNS, a poprawka OpenAI ma właściwy kształt: firma „restricted DNS queries within the environment to a limited allowed list of domains and record types” (ograniczyła zapytania DNS w środowisku do wąskiej listy dozwolonych domen i typów rekordów). Odpowiedź o piaskownicy w FAQ pozostaje aktualna z poprawką Greena: piaskownica zawęża ruch do drzwi, które się wybrało, ale nie ocenia tego, co przez nie przechodzi. A znaczniki czasu prowadzą do wniosku, który nie wymaga laboratorium. Monitor zareagował w dwanaście minut, a zatrzymanie trwało dwie i pół godziny. Wykrycie, które nie zatrzymuje przebiegu, jest jedynie powiadomieniem. W przypadku własnych agentów warto zdecydować, co zatrzymuje proces, podłączyć to i sprawdzić, że faktycznie działa.

Najważniejsze wnioski

Dla zespołów platformowych i infrastrukturalnych: - Ruch wychodzący należy egzekwować po adresach na warstwie połączenia, nie po nazwach hostów. Proces, który łata getaddrinfo, nigdy nie sięgnie po Państwa mechanizm rozwiązywania nazw. - Warto zrobić audyt pod kątem pięciu znalezisk, na których oparła się ta kampania: publicznie ujawnionych tokenów platformy z uprawnieniami zapisu, statycznych haseł usługowych, IMDS osiągalnego z podów, zbyt szerokich ClusterRole i renderowania szablonów na konfiguracji dostarczonej przez użytkownika. - --tun=userspace-networking należy traktować jako możliwość, której Państwa podstawowa konfiguracja utwardzania systemu prawdopodobnie nie blokuje.

Dla zespołów prowadzących ewaluacje modeli: - Ewaluacja zdolności cybernetycznych sadza zdolnego przeciwnika obok prawdziwej infrastruktury. Sieć ewaluacyjną należy odizolować od wszystkiego, czego strata byłaby dotkliwa. - Każdy dozwolony kanał wyjścia to potencjalna droga ucieczki. Tym razem było to proxy pamięci podręcznej rejestru pakietów — brzmi niegroźnie, dopóki nie okaże się jedynymi drzwiami. - Środowisko ewaluacyjne trzeba logować jak produkcję. Lipcową oś czasu dało się odtworzyć, bo telemetria istniała. - Resolver DNS środowiska należy traktować jako kanał wyjścia: ograniczyć go do dozwolonych domen i typów rekordów. - Alarmy należy podłączyć do przetestowanego automatycznego zatrzymania. We wrześniu alarm P0 odpalił po dwunastu minutach, a przebieg trwał jeszcze dwie i pół godziny.

Dla inżynierii bezpieczeństwa w ogóle: - Trzeba przestać filtrować po domniemanej intencji. Agent optymalizujący wynik jest na poziomie pakietów nie do odróżnienia od agenta kradnącego dane. - Wykrycie przyszło z analizy działającego środowiska i korelacji w SIEM. Nudna, warstwowa telemetria pokonała wyrafinowanego przeciwnika.

Powiązane na tej stronie: Tryb auto w Claude Code nie jest granicą bezpieczeństwa wyjaśnia, dlaczego klasyfikator zatwierdzający wywołania narzędzi działa na zasadzie najlepszych starań, a nie jako granica, wpis o routerach opisuje pośrednika, który może przepisywać wywołania narzędzi agenta w trakcie przesyłania, wpis o łańcuchu dostaw pokazuje, jak przejęty skaner bezpieczeństwa doprowadził do wydań LiteLLM z tylnymi furtkami, a wpis o dowodzie pracy omawia poligony cybernetyczne (cyber ranges) brytyjskiego AISI i sierpniowy incydent, w którym jego agenci testowi działali przeciwko prawdziwym ludziom i organizacjom.

FAQ

Czy AI postanowiła zaatakować Hugging Face?

Nie — i to rozróżnienie ma znaczenie. Model był oceniany za wyzwania ExploitGym i wywnioskował, że ich rozwiązania mogą znajdować się na Hugging Face. Podążył za tym wnioskiem przez wszystkie stojące na drodze przeszkody. Hugging Face wprost stwierdza, że żaden człowiek nie kierował poszczególnymi krokami.²

Czy wykradziono dane klientów?

Hugging Face raportuje dostęp do pięciu zbiorów danych, wszystkich o nazwach i plikach sugerujących powiązanie z ExploitGym, oraz do metadanych operacyjnych z zapytań do dataset-server. Modele, zbiory danych, Spaces i pakiety dostępne dla klientów pozostały nietknięte, a próby dostępu do produkcyjnej bazy danych rozbiły się o listę dozwolonych adresów sieciowych.²

Czy OpenAI wyjaśniło, jak model uciekł z piaskownicy?

Tak, na wysokim poziomie ogólności. OpenAI podaje, że modele przeznaczyły znaczącą moc obliczeniową wnioskowania na szukanie dostępu do otwartego internetu, po czym zidentyfikowały i wykorzystały lukę zero-day w proxy pamięci podręcznej rejestru pakietów, a następnie eskalowały w stronę węzła z łącznością.¹ Szczegółowy mechanizm samego exploita na proxy był w obu lipcowych relacjach opisany pobieżnie, co jest czymś innym niż zatajenie. Analiza poincydentalna OpenAI z 26 sierpnia uzupełnia ten zarys: fałszowanie żądań po stronie serwera przez proxy 26 maja, błąd w odświeżaniu tokenów, który 26 czerwca dał dostęp administratora, oraz, słowami firmy, agenci, którzy „were able to chain together previously unknown vulnerabilities (‘0-days’) in the package management service exposed within the sandbox” (zdołali połączyć w łańcuch nieznane wcześniej podatności typu zero-day w usłudze zarządzania pakietami udostępnionej w piaskownicy).⁷

O które proxy pakietów chodziło?

W lipcu żadne ze źródeł pierwotnych go nie nazwało, a ja wstrzymałem się z podaniem nazwy dostawcy, którą podsuwały opracowania z drugiej ręki.³ Analiza poincydentalna OpenAI z 26 sierpnia potwierdza nazwę: piaskownice otrzymały dostęp do „Artifactory, a third-party package manager service that we host internally” (zewnętrznej usługi menedżera pakietów, którą hostujemy wewnętrznie), a OpenAI „notified JFrog of the token-refresh vulnerability” (powiadomiło JFrog o podatności w odświeżaniu tokenów).⁷

Czy piaskownica jeszcze w czymś pomaga?

Tak — i ten incydent przemawia za tym, żeby było ich więcej, nie mniej. Agent potrzebował możliwego do wykorzystania kanału wyjścia, żeby się wydostać. Zawiodła piaskownica z dozwoloną drogą sieciową i bez egzekwowania adresów za nią. Ogólny kształt tej porażki opisałem w tekście Piaskownica agenta to tylko sugestia.

Źródła