Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Mechanizmy sandboxingu w narzędziach AI dla programistów mają ograniczać skutki działań agenta, izolując go od systemu gospodarza i krytycznych zasobów stacji roboczej. Najnowsze ustalenia badaczy pokazują jednak, że sama izolacja procesu nie gwarantuje bezpieczeństwa, jeśli pliki tworzone w sandboxie są później uruchamiane, analizowane lub interpretowane przez zaufane komponenty działające już poza piaskownicą.
W praktyce oznacza to, że agent AI nie musi bezpośrednio przełamywać izolacji. Wystarczy, że przygotuje odpowiedni artefakt w obszarze roboczym, który uruchomi dalszy łańcuch wykonania po stronie hosta. To istotna zmiana w sposobie myślenia o zagrożeniach związanych z agentowym programowaniem.
W skrócie
Badacze bezpieczeństwa wykazali obejścia mechanizmów sandbox w czterech popularnych narzędziach wspierających programowanie z użyciem AI: Cursor, Codex CLI, Gemini CLI oraz Antigravity. Ataki opierały się na pośrednim wykonaniu kodu lub poleceń przez zaufane narzędzia hosta, które przetwarzały pliki zapisane wcześniej przez agenta w workspace.
- Problem dotyczy architektury zaufania, a nie wyłącznie pojedynczego błędu implementacyjnego.
- Część podatności została już załatana przez dostawców.
- Jedna z opisanych luk otrzymała identyfikator CVE-2026-48124.
- Szczególnie niebezpieczne okazały się hooki, konfiguracje projektu, integracje Git oraz dostęp do lokalnych usług uprzywilejowanych.
Kontekst / historia
Ujawnione przypadki wpisują się w szerszą serię badań nad ucieczkami z sandboxów w narzędziach AI dla programistów. Scenariusze ataku pokazały, że agent może formalnie pozostawać w środowisku ograniczonym, a mimo to wpływać na działanie komponentów hosta poprzez pliki projektu, metadane repozytorium, hooki czy konfiguracje wykorzystywane przez IDE i narzędzia developerskie.
To ważny sygnał dla rynku AI coding assistants. Wiele takich rozwiązań korzysta z lokalnych rozszerzeń, interpreterów, tasków edytora, integracji Git oraz usług systemowych. Jeśli którykolwiek z tych elementów zaufa danym wygenerowanym przez agenta, granica bezpieczeństwa między sandboxem a hostem staje się w praktyce iluzoryczna.
Opisywane ustalenia potwierdzają też wcześniejsze ostrzeżenia branżowe dotyczące konfiguracyjnych ucieczek z sandboxa. Tym razem problem został jednak pokazany na przykładzie kilku produktów, co wskazuje na powtarzalny wzorzec architektoniczny, a nie odosobniony incydent.
Analiza techniczna
Rdzeniem problemu jest błędne założenie, że pliki zapisane przez agenta w workspace są pasywne. W rzeczywistości mogą stanowić dane wejściowe dla procesów uruchamianych już poza sandboxem. Jeżeli hostowy komponent ufa takim plikom i potraktuje je jako konfigurację, skrypt, metadane lub polecenie pośrednie, dochodzi do wykonania poza zakresem izolacji.
Badacze wyróżnili kilka klas słabości. Pierwsza obejmuje sandboxy oparte na denylistach, które nie uwzględniają wszystkich możliwych ścieżek wykonania i zachowań systemu operacyjnego. Druga dotyczy konfiguracji workspace, które są traktowane przez użytkowników jak zwykłe pliki projektu, choć w praktyce prowadzą do wykonania logiki po stronie hosta. Trzecia to mechanizmy allowlisty poleceń bazujące jedynie na nazwie komendy, bez analizy argumentów i skutków ubocznych. Czwarta klasa obejmuje lokalne usługi uprzywilejowane, które mogą stać się pomostem do wykonania operacji poza sandboxem.
W przypadku Cursor opisano kilka niezależnych ścieżek ataku. Jedna z nich wykorzystywała hooki kontrolowane przez workspace, prowadząc do niesandboxowanego wykonania poleceń. Ten przypadek jest śledzony jako CVE-2026-48124 i według dostępnych informacji został naprawiony w wersji 3.0.0. Inne scenariusze obejmowały manipulację interpreterem w virtualenv oraz nadużycie metadanych Git w sposób omijający reguły zależne od lokalizacji ścieżki.
W Codex CLI problem objął między innymi listę dozwolonych poleceń uznawanych za bezpieczne. Przykład z komendą git show pokazał, że sama nazwa programu nie przesądza o charakterze operacji. Jeżeli system nie ocenia argumentów, kontekstu wykonania i skutków wywołania, możliwe jest obejście polityki bezpieczeństwa mimo formalnego użycia polecenia z allowlisty.
Istotny wektor dotyczył również lokalnego interfejsu Dockera. Uprzywilejowany daemon dostępny z poziomu narzędzi AI mógł posłużyć jako element łańcucha wykonania poza sandboxem. To szczególnie groźny model, ponieważ agent nie musi uzyskiwać bezpośredniego dostępu do systemu gospodarza, jeśli może wpływać na usługę posiadającą już szerokie uprawnienia.
W przypadku Antigravity wskazano obejścia powiązane z mechanizmami systemowymi i konfiguracjami zadań edytora. Wniosek jest spójny dla wszystkich badanych produktów: realna powierzchnia ataku znajduje się na styku agenta, plików projektu i zaufanych komponentów hosta.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją takich podatności jest zatarcie granicy między izolowanym agentem AI a rzeczywistą stacją roboczą programisty. Atak może rozpocząć się od pozornie niegroźnego artefaktu, takiego jak README, issue, diff, zależność lub konfiguracja projektu. Jeśli agent przetworzy tę treść i zapisze ją w formie interpretowanej później przez host, dochodzi do pośredniej eskalacji wpływu.
W środowiskach developerskich skutki mogą być bardzo poważne. Możliwe konsekwencje obejmują uruchomienie komend na hoście, modyfikację środowiska pracy, kradzież sekretów, manipulację kodem źródłowym, a w niektórych scenariuszach także dalszy ruch boczny w infrastrukturze organizacji.
Dodatkowym problemem pozostaje wykrywanie. Z perspektywy monitoringu agent może zachowywać się zgodnie z polityką i nie wykonywać niczego jawnie zabronionego. Faktyczne naruszenie następuje dopiero wtedy, gdy zaufany komponent hosta uruchomi lub zinterpretuje przygotowany wcześniej plik. To oznacza, że klasyczne monitorowanie samego procesu agenta może nie wystarczyć do wykrycia incydentu.
Rekomendacje
Organizacje korzystające z narzędzi AI do programowania powinny traktować workspace jako strefę danych nieufnych, nawet gdy projekt pochodzi z pozornie wiarygodnego źródła. Każdy plik utworzony lub zmodyfikowany przez agenta warto oceniać pod kątem tego, czy może zostać później wykonany lub zinterpretowany przez komponent hosta.
- Ograniczyć lub wyłączyć automatyczne wykonywanie hooków, tasków edytora i skryptów inicjalizacyjnych pochodzących z repozytorium.
- Kontrolować dostęp agentów i narzędzi developerskich do lokalnych daemonów uprzywilejowanych, szczególnie interfejsów Dockera.
- Regularnie aktualizować narzędzia AI coding assistant do wersji zawierających poprawki bezpieczeństwa.
- Analizować nie tylko nazwę komendy, lecz także jej argumenty, kontekst wykonania oraz możliwe skutki uboczne.
- Segmentować środowiska programistyczne i oddzielać projekty nieufne od systemów zawierających sekrety oraz dostęp produkcyjny.
- Monitorować momenty, w których procesy działające poza sandboxem interpretują lub uruchamiają pliki pochodzące z workspace.
- Szkolić zespoły w zakresie pośrednich prompt injection oraz zagrożeń wynikających z automatyzacji pracy przez agentów AI.
Najważniejsze pytanie nie powinno dziś brzmieć: czy narzędzie ma sandbox, ale raczej: które komponenty poza sandboxem ufają danym zapisanym przez agenta. To właśnie tam najczęściej powstaje realna ścieżka ataku.
Podsumowanie
Nowe przypadki sandbox escape w Cursorze, Codex CLI, Gemini CLI i Antigravity pokazują, że bezpieczeństwo agentów AI nie zależy wyłącznie od izolacji procesu. Kluczowe znaczenie ma cały łańcuch zaufania obejmujący IDE, rozszerzenia, interpretery, integracje Git, hooki, taski oraz lokalne usługi systemowe.
Dla zespołów bezpieczeństwa i inżynierii to wyraźny sygnał, że należy przeglądnąć architekturę narzędzi AI, zaostrzyć polityki dla workspace i kontrolować każdy moment przejścia od danych projektu do wykonania po stronie hosta. Problem ma charakter systemowy i może wpływać na szeroki ekosystem agentowego programowania.
Źródła
- BleepingComputer — https://www.bleepingcomputer.com/news/security/cursor-codex-gemini-cli-antigravity-hit-by-sandbox-escapes/
- Week of Sandbox Escapes — https://www.pillar.security/week-of-sandbox-escapes
- CVE-2026-48124 — https://github.com/advisories/GHSA-8m9x-3wqm-wr3v
- Pillar Security: Docker socket finding affecting Codex, Cursor and Gemini CLI — https://github.com/pillar-security/sandbox-escapes
- Cymulate: Configuration-Based Sandbox Escape — https://cymulate.com/blog/configuration-based-sandbox-escape/