AnswersPublished20 sources
Heapjack i Overpatch: jak doszło do ucieczek z piaskownicy OpenAI Codex
Heapjack i Overpatch mogły ominąć zakładane granice Codex i prowadzić do działań na hoście z poziomu niezaufanego repozytorium. Heapjack dotyczył globalnie skonfigurowanego pomocnika node repl i współdzielonej sterty V8, a Overpatch — uprawnień apply patch wyliczanych na podstawie ścieżek z łatki kontrolowanej przez...
Opublikowane przezEdytowane za pomocą GPT-5.6 TerraObrazy wygenerowane za pomocą GPT Image 2
Research answer
Key takeaways
- Heapjack i Overpatch mogły ominąć zakładane granice Codex i prowadzić do działań na hoście z poziomu niezaufanego repozytorium.
- Heapjack dotyczył globalnie skonfigurowanego pomocnika node repl i współdzielonej sterty V8, a Overpatch — uprawnień apply patch wyliczanych na podstawie ścieżek z łatki kontrolowanej przez atakującego.
- Podobne ucieczki agentów z 2026 r. związane z konfiguracją Git miały inny mechanizm, lecz ten sam problem architektoniczny: niesandboxowana warstwa orkiestracji respektowała dane kontrolowane przez repozytorium.
AI Prompt
openai.comCreate a landscape editorial hero image for this Studio Global article: How did Accomplish AI researchers’ Heapjack and Overpatch vulnerabilities enable sandbox escapes and host-command execution in OpenAI’s Code. Article summary: Accomplish’s two findings bypassed Codex’s intended workspace/read-only boundaries by making a trusted enforcement component rely on attacker-influenced state. Both could turn an untrusted repository into host-level code. Topic tags: general, general web. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts with fake numbers, clic
Sandbox Codex miał ograniczać to, co agent programistyczny może odczytać, zapisać i uruchomić. Ustalenia firmy Accomplish AI, nazwane Heapjack i Overpatch, pokazały jednak, że granicę można było ominąć, gdy zaufany komponent współdzielił sekret z niezaufanym kodem albo wyprowadzał uprawnienia z danych kontrolowanych przez atakującego. Obie luki zostały zgłoszone i załatane. 4
8
Heapjack: sekret autoryzacyjny na współdzielonej stercie
Heapjack dotyczył integracji node_repl instalowanej przez Codex Desktop. Według badaczy aplikacja Desktop zapisywała konfigurację serwera MCP w globalnym pliku ~/.codex/config.toml. Oznaczało to, że sesje CLI korzystające ze współdzielonej konfiguracji mogły odziedziczyć ten pomocniczy komponent. 8
9
Kluczowy błąd separacji znajdował się w środowisku JavaScript tego komponentu:
- zaufany kontekst przechowywał token autoryzacyjny przypisany do danego uruchomienia;
- niezaufany kontekst, kontrolowany przez agenta, działał na tej samej stercie V8;
- niezaufana strona mogła odzyskać token i używać go do żądań, które natywny proces nadrzędny uznawał za autoryzowane.
8
15
Ponieważ proces nadrzędny działał poza sandboxem, skutkiem mogły być działania na poziomie hosta — w tym wykonanie poleceń — nawet gdy Codex działał nominalnie w trybie tylko do odczytu. Problemem nie było samo uruchamianie JavaScriptu, lecz to, że poświadczenie odróżniające zaufaną pracę od niezaufanej znajdowało się w pamięci dostępnej dla niezaufanej strony. 8
15
Overpatch: uprawnienia poszerzane przez treść łatki
Overpatch był błędem w Codex CLI, dotyczącym apply_patch w trybie zapisu do obszaru roboczego (workspace-write). Narzędzie miało ograniczać edycje do katalogu projektu, ale jego mechanizm autoryzacji przyznawał zakres zapisu na podstawie katalogów nadrzędnych ścieżek wskazanych w samej łatce. 4
To sprawiło, że ścieżki w łatce stały się danymi istotnymi dla bezpieczeństwa. Accomplish opisało dowód koncepcji, w którym pozornie nieskuteczna ścieżka, taka jak /tmp, powodowała rozszerzenie uprawnień do katalogu głównego systemu plików. Druga zmiana w łatce prowadziła następnie przez dowiązanie symboliczne kontrolowane przez repozytorium i modyfikowała plik poza obszarem roboczym, w tym plik inicjalizacyjny powłoki w katalogu domowym użytkownika. 4
9
Konsekwencja bezpieczeństwa była odroczona, ale realna: kod dodany do pliku startowego powłoki mógł wykonać się poza sandboxem agenta, gdy programista później otworzył terminal. Wynikające z tego działanie na hoście nie wymagało standardowego monitowania o zatwierdzenie. 4
7
Wspólny problem: uprzywilejowany komponent zaufał niewłaściwym danym
Heapjack i Overpatch wykorzystywały różne ścieżki techniczne, ale ujawniły ten sam problem projektowy: mechanizm egzekwujący zasady ufał danym dostępnym po niezaufanej stronie granicy.
| Luka | Czego dotyczyło zaufanie | Dlaczego granica zawiodła |
|---|---|---|
| Heapjack | Tokenu autoryzacyjnego na współdzielonej stercie V8 | Niezaufany kod mógł odzyskać sekret używany do odróżniania autoryzowanych żądań. |
| Overpatch | Ścieżek dostarczonych w łatce kontrolowanej przez agenta | Ścieżki wpływały na zakres uprawnień do zapisu, zamiast tylko opisywać planowaną edycję. |
To przykład problemu confused deputy (uprzywilejowanego pośrednika działającego na podstawie niewłaściwie zweryfikowanego żądania). Komponent lub warstwa orkiestracji o wyższych uprawnieniach wykonuje działanie w imieniu wejścia o niższym poziomie zaufania, bez bezpiecznego sprawdzenia uprawnień albo ostatecznego celu operacji.
Samo objęcie sandboxem powłoki agenta nie wystarcza więc wtedy, gdy pomocniki, tokeny, konfiguracja i procesy orkiestrujące pozostają uprzywilejowane lub mogą być kształtowane przez zawartość repozytorium.
Jak wpisują się w to ucieczki związane z Git
Inne ujawnione w 2026 r. ucieczki z sandboxów agentów programistycznych różniły się technicznie, lecz były architektonicznie podobne. Raporty Accomplish o Beltdown i Beltdown2 opisywały przypadki, w których powłoka agenta była izolowana, ale wewnętrzne polecenia Git uruchamiane przez otaczającą ją warstwę działały już poza sandboxem. Plik .git/config repozytorium mógł używać ustawienia Git core.fsmonitor, aby Git uruchamiał skonfigurowany program pomocniczy przy sprawdzaniu drzewa roboczego. 17
18
Manifold Security określiło szerszą klasę takich problemów mianem GitSpawn: konfiguracja Git kontrolowana przez repozytorium mogła spowodować uruchomienie kodu wybranego przez atakującego podczas inspekcji projektu przez agenta — potencjalnie zanim użytkownik podejmie istotną decyzję o zaufaniu lub zatwierdzeniu. 20
21
Wniosek nie jest taki, że każde repozytorium jest automatycznie niebezpieczne w każdym procesie pracy. Należy jednak traktować repozytorium jako potencjalnie aktywne dane wejściowe, gdy narzędzia odczytują metadane, rozwiązują dowiązania symboliczne, stosują łatki, uruchamiają hooki lub wywołują procesy pomocnicze. Granica zaufania produktu agenta obejmuje wszystkie te ścieżki, a nie wyłącznie widoczne narzędzie do wykonywania poleceń.
Wersje Codex zawierające poprawki
Minimalne zgłoszone wersje z poprawkami to:
- Codex Desktop, kompilacja 26.818.21641 lub nowsza — dla Heapjack.
9
- Codex CLI, wersja 0.149.0 lub nowsza — dla Overpatch.
4
Accomplish podało, że zgłosiło obie luki OpenAI 12 sierpnia 2026 r., a poprawki pojawiły się w ciągu ośmiu dni. 9
Co zrobić przed otwarciem niezaufanego repozytorium
- Zaktualizuj zarówno Desktop, jak i CLI. Luki dotyczyły różnych komponentów, a globalny pomocnik instalowany przez Desktop mógł wpływać na sesje CLI używające współdzielonej konfiguracji.
- Traktuj zawartość repozytorium jako coś więcej niż kod źródłowy. Dowiązania symboliczne, ścieżki w łatkach, pliki konfiguracyjne, hooki i metadane Git mogą wpłynąć na działania agenta lub jego warstwy orkiestrującej.
20
- Nie udostępniaj w takim środowisku wrażliwych zasobów hosta. Dotyczy to długotrwałych poświadczeń, kluczy SSH, tokenów chmurowych, gniazd Docker oraz poufnych plików z katalogu domowego.
- Do rzeczywiście niezaufanych projektów stosuj zewnętrzną izolację. Jednorazowa maszyna wirtualna lub podobnie silnie odseparowane środowisko zapewnia osobną granicę ochrony, gdy agent, pomocnik lub warstwa orkiestracji zostaną naruszone.
- Zachowaj szczególną ostrożność wobec repozytoriów dostarczonych w całości. Ryzyko w stylu GitSpawn jest szczególnie istotne, gdy projekt trafia jako archiwum, przez dysk współdzielony, folder synchronizowany lub nośnik wymienny, które zachowują metadane
.git; zwykłe klonowanie zazwyczaj nie przenosi lokalnego pliku.git/configze zdalnego repozytorium.22
Praktyczny wniosek jest prosty: zainstaluj poprawione komponenty Codex, ale nie traktuj sandboxa działającego wewnątrz procesu jako jedynej bariery między nieznanym repozytorium a stacją roboczą programisty.
Studio Global AI
Continue your research
This page includes a source-backed answer you can continue inside Studio Global.
People also ask
What is the short answer to "Heapjack i Overpatch: jak doszło do ucieczek z piaskownicy OpenAI Codex"?
Heapjack i Overpatch mogły ominąć zakładane granice Codex i prowadzić do działań na hoście z poziomu niezaufanego repozytorium.
What are the key points to validate first?
Heapjack i Overpatch mogły ominąć zakładane granice Codex i prowadzić do działań na hoście z poziomu niezaufanego repozytorium. Heapjack dotyczył globalnie skonfigurowanego pomocnika node repl i współdzielonej sterty V8, a Overpatch — uprawnień apply patch wyliczanych na podstawie ścieżek z łatki kontrolowanej przez atakującego.
What should I do next in practice?
Podobne ucieczki agentów z 2026 r. związane z konfiguracją Git miały inny mechanizm, lecz ten sam problem architektoniczny: niesandboxowana warstwa orkiestracji respektowała dane kontrolowane przez repozytorium.
Sources