Badacze wydostają się z piaskownicy OpenAI Codex i wykonują polecenia na hoście

Badacze bezpieczeństwa znaleźli dwie metody wydostania się z piaskownicy OpenAI Codex, jedna z nich umożliwiała uruchamianie poleceń na maszynie dewelopera z trybu najbardziej zamkniętej piaskownicy Codex, bez żądania potwierdzenia i bez wyświetlania jakichkolwiek komunikatów na ekranie.

Oba błędy zostały zgłoszone OpenAI 12 sierpnia i poprawione w ciągu ośmiu dni, według Oren Yomtova z Accomplish AI.

Poważniejszy z nich, określany jako Heapjack, przekształca rutynowe działanie w zdalne wykonanie kodu: otwarcie czyjegoś repozytorium w Codex, zadanie mu pytania o kod i zdalne uruchomienie nieuporządkowanych poleceń na komputerze użytkownika.

Codex to agent programistyczny OpenAI dostępny jako narzędzie wiersza poleceń oraz aplikacja pulpitu. Podobnie jak rywalizujące agenty, działa w izolowanym środowisku, które ma zapobiec nieuporządkowanym kodom dotykania szerszego systemu. Oba rodzaje ucieczki polegają na przełamaniu tego ograniczenia z wnętrza.

Technika Heapjack, opisana w raporcie Yomtova, atakuje komponent o nazwie node_repl, który Codex Desktop zapisuje do globalnego pliku konfiguracyjnego '~/.codex/config.toml' podczas instalacji.

Nie ma możliwości włączenia lub wyłączenia tej funkcji, a ponieważ wpis znajduje się w wspólnej konfiguracji, zwykli użytkownicy CLI Codex również ją odziedziczą bez żadnego pytania.

node_repl uruchamia pojedynczy proces Node.js, który przechowuje dwie osobne konteksty wykonania JavaScript. Jeden jest zaufany i zawiera własny kod OpenAI, drugi jest niezaufany i wykonuje kod agenta. Kontekst zaufany potwierdza swoją zaufaność poprzez przedstawienie losowego tokenu generowanego przy każdym uruchomieniu.

Problem polega na tym, że oba konteksty znajdują się w jednym procesie Node.js i dzielą wspólną pamięć kopca, więc token jest po prostu ciągiem znaków w pamięci, który strona niezaufana może odczytać.

Strona niezaufana wykonuje migawkę kopca przy pomocy 'v8.getHeapSnapshot()' i próbuje każdy ciąg znaków przypominający UUID. Błędna próba zwraca komunikat "not authorized", a prawidłowy token z nieprawidłowym argumentem zwraca prawdziwy błąd weryfikacji, co informuje atakującego, że token jest poprawny.

Za pomocą tokenu strona niezaufana zapisuje własne żądanie na tym samym kanale, którym zaufany kontekst komunikuje się z niesandbowanym procesem nadrzędnym.

Proces nadrzędny sprawdza token, widzi poprawny, i wykonuje działanie. Dowód koncepcji wykorzystał polecenie systemowe 'open' do uruchomienia aplikacji poza drzewem procesów Codex. Ten sam dostęp sięga dowolnego unixowego gniazda gniazdowego, gniazda gniazdowego Docker oraz narzędzia do edycji globalnej konfiguracji.

Wszystko to działa w trybie tylko do odczytu, najściślej izolowanym, w którym agent nie powinien w ogóle nic pisać.

Drugi błąd, Overpatch, znajduje się w open-source kodowej linii komend Codex. W trybie workspace-write agent może zapisywać wyłącznie w katalogu projektu, a polecenie powłoki skierowane do katalogu domowego jest odrzucane.

Badacze wykorzystali własne narzędzie naprawcze Codex o nazwie apply_patch, aby wykonać zapis w katalogu domowym.

Narzędzie to przyznaje prawa zapisu do katalogu nadrzędnego każdego ścieżki wymienionej w poprawce. Jeśli nazwano '/tmp', przyznano zapisu do korzenia dysku.

Eksploatacja użyła poprawki składającej się z dwóch zmian: pierwsza nazwała '/tmp' i nie robiła nic użytecznego, oprócz rozszerzenia uprawnień, a druga dopisała linię do '.zshrc' poprzez symlink w katalogu domowym.

Usunięcie pierwszej zmiany spowodowałoby odrzucenie zapisu. Z nią natomiast kolejny otwarty terminal dewelopera uruchamia linię atakującego bez izolacji.

Oba błędy mają podobną strukturę: mechanizm egzekwowania znajdował się wewnątrz tego, co miał egzekwować. apply_patch wyprowadził własne uprawnienia z wejścia dostarczonego przez atakującego. node_repl przechowywał tajemnicę rozróżnienia zaufanego od niezaufanego w tym samym pamięci co kod niezaufany.

W obu przypadkach piaskownica została poinformowana, z wnętrza, aby przepuścić coś przez.

Klasa tego błędu nie jest nowa. W lipcu 2026 r. badacze z Pillar Security pokazali podobny mechanizm w Cursor, Codex, Gemini CLI i Google Antigravity, gdzie agent pozostający wewnątrz piaskownicy zapisuje plik, który później uruchamia zaufane narzędzie poza piaskownicą.

Reakcjonując na wpis Yomtova w serwisie X, jeden z komentatorów napisał, że "V8 izoluje konteksty, nie pamięć, więc piaskownica była naprawdę obietnicą, której kopiec nigdy nie zgodził się spełnić". Inny określił granicę zaufania jako "podział pokoju". Domyślnie włączone zachowanie przyciągnęło uwagę, z pytaniem, dlaczego token uprawniony był dostępny z niezaufanego kodu JavaScript w ogóle.

OpenAI poprawił Heapjack w wersji Codex Desktop build 26.818.21641 oraz Overpatch w Codex CLI 0.149.0, według Accomplish.

Użytkownicy powinni zaktualizować się do tych wersji lub nowszych. Yomtov podziękował OpenAI za rozwiązanie obu problemów w ciągu ośmiu dni od zgłoszenia.

BleepingComputer skontaktowało się z OpenAI przed publikacją.

W oświadczeniu dla BleepingComputer dzisiaj przedstawiciel OpenAI podziękował badaczom:

"Podziękujemy badaczom za kontakt i podzielenie się swoimi wnioskami. Zajęliśmy się obiema problemami w sierpniu, ale nieustannie wzmocniamy nasze piaskownie, wprowadzając ostatnie aktualizacje, które ściśle ograniczają miejsca, w które agenty mogą zapisywać pliki i poszerzają testy tych ochron na wszystkich platformach."

Update, 21 września, 05:29 AM ET: Dodano oświadczenie od OpenAI po publikacji.

Zbuduj swoją strategię bezpieczeństwa wobec ataków napędzanych przez sztuczną inteligencję

Dołącz do Mikko Hyppönena i liderów bezpieczeństwa z NFL, CHANEL i Atlassian na dwugodzinny cyfrowy szczyt o tym, jak ataki z prędkością sztucznej inteligencji zmieniają obraz, co powinni przestać robić obrońcy, oraz jak walidować, decydować, naprawiać i ponownie walidować w tempie maszynowym.