Dwie drogi wyjścia z piaskownicy OpenAI Codex: Heapjack i Overpatch

15 września 2026 r. Oren Yomtov, główny badacz bezpieczeństwa w Accomplish AI, opublikował techniczny opis dwóch odrębnych sposobów wydostania się z piaskownicy otaczającej agenta kodującego Codex firmy OpenAI. Oba zgłoszono OpenAI 12 sierpnia 2026 r. i oba naprawiono w ciągu ośmiu dni, według jego opracowania: Heapjack w kompilacji Codex Desktop 26.818.21641 i Overpatch w Codex CLI 0.149.0. Heapjack jest poważniejszy z tych dwóch. Nie wymaga od osoby atakowanej niczego poza otwarciem repozytorium w Codex i zadaniem pytania o kod, a działa w trybie tylko do odczytu, najsurowszym trybie oferowanym przez produkt, bez monitu zatwierdzenia i bez niczego wyświetlanego na ekranie. Według Cloud Security Alliance żadnej z tych luk nie przypisano CVE i nie opublikowano odrębnego biuletynu OpenAI, a nie zgłoszono, by ktokolwiek został przez nie poszkodowany. Jest skatalogowany obok innych tegorocznych wpisów dotyczących kontroli agentów w archiwum incydentów AI, gdzie każdy rekord zawiera swoje dokumenty źródłowe, ocenę pewności i flagę sporności.

Heapjack: token znajdował się w stercie, którą niezaufana strona mogła odczytać

Codex Desktop nie pyta przed zainstalowaniem komponentu zaatakowanego przez Yomtova. Podczas instalacji zapisuje blok node_repl w globalnym pliku konfiguracyjnym pod ~/.codex/config.toml, a Yomtov donosi, że nie ma opcji opt-in ani ustawienia, które by to wyłączało. Ponieważ wpis znajduje się we współdzielonej konfiguracji, a nie w indywidualnym wyborze użytkownika, zwykły użytkownik Codex CLI dziedziczy to samo narzędzie, mimo że nigdy nie został o to zapytany.

Narzędzie node_repl jest samo w sobie natywnym programem działającym poza piaskownicą. Może otwierać aplikacje, łączyć się z gniazdami Unix i edytować globalny plik konfiguracyjny. To, co uruchamia wewnątrz piaskownicy, to pojedynczy proces Node.js, a proces ten zawiera dwa konteksty wykonawcze JavaScript: zaufany, zawierający własny kod OpenAI, oraz niezaufany, wykonujący to, o co poproszono agenta.

Zaufany kontekst dowodzi, że jest zaufany, prezentując losowy token generowany od nowa przy każdym uruchomieniu. Ma to wyznaczać granicę między oboma kontekstami. Nią nie jest, ponieważ oba konteksty żyją w jednym izolacie V8, współdzieląc jedną stertę pamięci, więc token to ciąg znaków siedzący w pamięci, który niezaufany kod może odczytać. Komentator reagujący na ujawnienie na X ujął to dosadniej, w zdaniu, które BleepingComputer zacytował: „Konteksty V8 izolują obiekty globalne, nie pamięć, więc piaskownica była w rzeczywistości obietnicą, na którą sterta nigdy nie przystała”. To charakterystyka, nie dowód; dowodem jest proof of concept.

Exploit Yomtova robi dokładnie to, co sugeruje ten opis. Niezaufany JavaScript wywołuje v8.getHeapSnapshot(), skanuje wynikowy zrzut sterty w poszukiwaniu ciągów o kształcie UUID i testuje każdego kandydata. Błędne przypuszczenie zwraca „not authorized”. Prawidłowy token w parze z nieprawidłowym argumentem zwraca natomiast prawdziwy błąd walidacji. Różnica między tymi dwoma komunikatami błędów jest wyrocznią, która identyfikuje właściwą wartość.

Mając token w ręku, proces w piaskownicy zapisuje własne żądanie JSON do deskryptora pliku 1 — tego samego potoku stdout, którego zaufany kontekst używa do komunikacji z natywnym procesem nadrzędnym. Proces nadrzędny weryfikuje token, stwierdza, że jest ważny, i wykonuje zadanie. W proof of concept tym zadaniem było systemowe polecenie open, które przekazuje żądanie do launchd i uruchamia aplikację całkowicie poza drzewem procesów Codex. Ten sam token pozwala na połączenia z dowolnymi gniazdami Unix, w tym z gniazdem demona Dockera, i sięga do narzędzia do edycji globalnego pliku konfiguracyjnego.

To wszystko działa w trybie tylko do odczytu — trybie, który ostrożny użytkownik wybiera właśnie dlatego, że repozytorium przed nim nie jest zaufane. Na żadnym etapie nie pojawiło się okno zatwierdzenia. Praktyczny scenariusz jest krótki: otwórz sklonowane repozytorium w Codex w trybie tylko do odczytu i zadaj pytanie o kod. Osoba, która napisała to repozytorium, uzyskuje możliwość wykonywania poleceń poza piaskownicą na maszynie, a nic na ekranie o tym nie informuje.

Overpatch: narzędzie do łatek, które nadawało rodzica wszystkiemu, czego dotknęło

Drugi błąd tkwi w Codex CLI, otwartoźródłowym agencie wiersza poleceń, i jest to błąd uprawnień, a nie błąd pamięci. W trybie workspace-write agent może zapisywać wyłącznie w folderze projektu i nigdzie indziej; polecenie powłoki skierowane do katalogu domowego jest odrzucane. Narzędzie apply_patch miało pilnować tej granicy. Zamiast tego czerpało uprawnienia ze ścieżek wymienionych w stosowanej łatce i przyznawało prawo zapisu katalogowi nadrzędnemu każdej z nich.

Podaj ścieżkę pod /tmp w łatce, a uprawnienie rozszerzy się na katalog główny dysku, ponieważ katalogiem nadrzędnym /tmp jest /. Na tym polega cały trik.

Działający exploit wykorzystuje dwa wpisy w jednej łatce. Pierwszy wskazuje /tmp i nie robi nic użytecznego — kończy się niepowodzeniem, ponieważ plik nie może nadpisać katalogu — i istnieje tylko po to, by rozszerzyć przyznane uprawnienie. Drugi dopisuje wiersz do .zshrc przez dowiązanie symboliczne do katalogu domowego. Usuń pierwszy wpis, a zapis zostanie odrzucony. Zostaw go, a następny terminal, który otworzy deweloper, uruchomi wiersz atakującego poza piaskownicą, przy czym piaskownica w ogóle nie będzie już w grze.

To sprawia, że Overpatch jest błędem trwałości, a nie jednorazowym incydentem. Zatruty plik startowy wykonuje się ponownie w każdej powłoce, którą otworzy deweloper, dopóki ktoś nie przeczyta .zshrc i nie zauważy dopisanej linii — dlatego wytyczne Cloud Security Alliance mówią, by szukać takiego mechanizmu, zamiast czekać na objaw.

Oba błędy umieszczają egzekwowanie wewnątrz rzeczy, która ma być egzekwowana

Własne ujęcie Yomtova to ta część, która wykracza poza Codex. apply_patch obliczał własne uprawnienia na podstawie danych wejściowych dostarczonych przez atakującego. node_repl przechowywał w pamięci sekret oddzielający kod zaufany od niezaufanego, a niezaufany kod mógł go odczytać. W każdym z tych przypadków piaskownicę poinformowano od wewnątrz, aby coś przepuściła.

Schemat nie jest nowy. BleepingComputer, który poinformował o ujawnieniu 20 września 2026 r., zauważa, że w lipcu 2026 r. badacze z Pillar Security zademonstrowali ten sam pomysł w Cursor, Codex, Gemini CLI oraz Antigravity firmy Google, gdzie agent pozostający w swoim sandboksie zapisuje plik, który następnie wykonuje zaufane narzędzie spoza sandboksu. Tym, co wyróżnia parę Codex, jest obejście trybu tylko do odczytu w Heapjack oraz brak jakiegokolwiek ustawienia umożliwiającego wyłączenie komponentu, który je zawiera.

Poprawki oraz to, co OpenAI powiedziało, a czego nie powiedziało

OpenAI naprawiło Heapjack w kompilacji Codex Desktop 26.818.21641 oraz Overpatch w Codex CLI 0.149.0 – według Accomplish. Obie poprawki trafiły w ciągu ośmiu dni od raportu z 12 sierpnia – do 20 sierpnia, jeśli dosłownie czytać ten harmonogram – a Yomtov przypisał tę zmianę na lepsze OpenAI.

OpenAI nie opublikowało odrębnego biuletynu bezpieczeństwa dotyczącego żadnej z tych luk i nie przypisano identyfikatora CVE; Cloud Security Alliance odnotowuje oba te braki w notatce badawczej z 22 września 2026 r. Poproszony o komentarz rzecznik OpenAI powiedział BleepingComputer: „Dziękujemy badaczom za kontakt i podzielenie się swoimi ustaleniami. Zajęliśmy się oboma problemami w sierpniu, ale stale wzmacniamy nasze piaskownice, a najnowsze aktualizacje zaostrzają kontrolę nad tym, gdzie agenci mogą zapisywać pliki, i rozszerzają testowanie tych zabezpieczeń na różnych platformach”.

To oświadczenie potwierdza poprawki i nic nie mówi o mechanizmach. Nie mówi, czy sierpniowe zmiany usunęły wzorzec projektowy, czy zamknęły dwie konkretne ścieżki wyjścia z niego. Nikt spoza OpenAI również tego nie stwierdził.

Co jest ustalone, a co opiera się na jednym badaczu

Archiwum klasyfikuje ten wpis jako wynik badania, waga wysoka, region globalny, pewność B — udokumentowane, ale pochodzące z jednego lub wtórnego źródła — bezsporne, bez odnotowanych rzeczywistych szkód. Ten stopień to właściwa perspektywa do czytania dalszej części tego tekstu, ponieważ podział między tym, co potwierdza kilka stron, a tym, co twierdzi wyłącznie znalazca, przewija się przez całą historię.

Ustalono w tym sensie, że twierdzi to więcej niż jedna strona:

• Ujawnienie istnieje i jest opatrzone datą. Artykuł Yomtova został opublikowany 15 września 2026 r.; obie wady zgłoszono OpenAI 12 sierpnia 2026 r. i według jego relacji zostały naprawione w ciągu ośmiu dni.

• OpenAI potwierdza, że podjęło działania w sierpniu. Rzecznik firmy powiedział BleepingComputer, że oba problemy zostały rozwiązane, co niezależnie od odkrywcy potwierdza harmonogram zgłoszenia i naprawy, mimo że spółka nie opublikowała żadnego biuletynu bezpieczeństwa ani własnego opisu technicznego.

Wersje z poprawkami są podawane spójnie. Build 26.818.21641 dla Codex Desktop i wersja 0.149.0 dla Codex CLI są podane przez Accomplish, powtórzone przez BleepingComputer i zawarte w biuletynie z 22 września 2026 r. od Uganda National Computer Emergency Response Team and Coordination Center, który ocenił tę parę jako „Red”.

• Brak CVE, brak biuletynu dostawcy i brak zgłoszonych przypadków wykorzystania. Notatka Cloud Security Alliance z 22 września 2026 r. odnotowuje brak zarówno CVE, jak i odrębnego biuletynu OpenAI, a także nie zgłasza żadnych potwierdzonych przypadków, w których organizacja wykryłaby działający mechanizm utrzymania dostępu Overpatch.

• Archiwum nie kwestionuje żadnego z tych elementów. Wpis jest oznaczony jako niesporny, a jego ocena wiarygodności odzwierciedla wzorzec źródłowy, a nie jakiekolwiek spory co do faktów.

Nie ustalone albo ustalone przez nikogo poza znalazcą:

• Szczegóły mechanizmu pochodzą od Yomtova. Wyrocznia zrzutu sterty, współdzielony deskryptor pliku, przyznanie uprawnień do katalogu nadrzędnego — wszystko to pochodzi z jego opracowania i jego proof of concept. Cloud Security Alliance, którego nota jest najbardziej szczegółowym podsumowaniem strony trzeciej w obiegu, w swojej nocie opisuje syntezę jego relacji i doniesień BleepingComputer, nie stwierdzając, że odtworzyło którykolwiek z exploitów lub przetestowało którąkolwiek z poprawek. Biuletyn CERT.UG zestawia ten sam materiał.

• Zakresy podatnych wersji nigdy nie zostały opublikowane. Wskazano tylko wersje z poprawkami, więc nie ma listy wcześniejszych kompilacji, które zawierały każdą z tych luk.

• Nie określono, czy załatana instalacja jest bezpieczna przed całą klasą błędów, a nie tylko przed tymi dwoma przypadkami. „Ciągłe wzmacnianie naszych piaskownic” ze strony OpenAI to ogólne zobowiązanie, a nie twierdzenie o konkretnym mechanizmie.

• Nie zgłoszono nikogo, kto wykorzystywałby którąkolwiek z tych luk. To brak zgłoszeń, a nie stwierdzenie braku — a proof of concept pokazuje, że ścieżka Heapjack nie pozostawia na ekranie niczego, co użytkownik mógłby zauważyć.

To, na co użytkownik może zareagować

Każdy, kto korzysta z kompilacji Codex Desktop starszej niż 26.818.21641 lub wersji Codex CLI starszej niż 0.149.0, znajduje się po podatnej stronie linii wyznaczanej przez Accomplish, a aktualizacja to jedyne remedium oferowane w ujawnieniu. Ponadto Cloud Security Alliance zaleca audytowanie poprzednich sesji Codex Desktop, które obejmowały niezaufane repozytoria, pod kątem aktywności związanej z launchd lub open oraz połączeń z gniazdem Dockera, a także czytanie plików startowych powłoki — .zshrc, .bashrc i ich odpowiedników — w poszukiwaniu poleceń, które zostały dopisane, a nie wpisane przez użytkownika.

Ta sama notatka odradza traktowanie trybu tylko do odczytu jako zabezpieczenia, gdy repozytorium jest niezaufane, co jest wnioskiem, do którego Heapjack dochodzi sam z siebie. Jej zalecenia strukturalne idą dalej: fizyczna izolacja procesów i pamięci zamiast współdzielonych sekretów i konwencji, poświadczenia trzymane poza zasięgiem agenta oraz patche odwołujące się do ścieżek poza projektem traktowane z góry jako podejrzane. To propozycje strony trzeciej. Czy OpenAI przyjęło którąkolwiek z nich poza dwoma podniesieniami numeru wersji, nie jest publicznie wiadome.

Na koniec warto rozdzielić dwie rzeczy. Jedna to para błędów w powszechnie używanym agencie kodującym, zgłoszonych 12 sierpnia 2026 r., naprawionych w ciągu ośmiu dni i zamkniętych w dwóch numerach kompilacji. Druga to kwestia projektowa, którą Yomtov nazywa — czy piaskownicę może wymuszać kod, który ma ona zawierać — a na to pytanie nie odpowiada żaden numer wersji. Ani Accomplish, ani OpenAI nie twierdzą, że sierpniowe zmiany tę kwestię rozstrzygają.