Luki w agentach AI do kodowania: Cursor i inne narzędzia

Bezpieczeństwo agentów AI do kodowania stało się gorącym tematem po tym, jak zespół Pillar Security ujawnił, że w czterech popularnych narzędziach – Cursor, Codex CLI od OpenAI, Gemini CLI oraz Antigravity od Google – istnieją luki pozwalające na ucieczkę z sandboxa. Co ważne, atakujący nie musi przełamywać zabezpieczeń bezpośrednio. Wystarczy, że agent wewnątrz izolowanego środowiska zapisze plik, który później zostanie uruchomiony przez zaufane narzędzie działające na hoście. Badacze Eilon Cohen, Dan Lisichkin i Ariel Fogel przez kilka miesięcy odtwarzali te scenariusze i opublikowali swoje odkrycia w serii wpisów zatytułowanej „Week of Sandbox Escapes”.

Jak agent AI może uciec z piaskownicy

Sandbox to prosta koncepcja: agent pracuje w izolowanym obszarze projektu, podczas gdy host pozostaje chroniony. Problem pojawia się, gdy pliki wewnątrz tego obszaru nie są bierne. Narzędzia działające poza sandboxem – na przykład rozszerzenia Pythona rozwiązujące interpretery, integracje Git skanujące repozytoria, zadania VS Code czy demon Docker – odczytują te pliki i wykonują na ich podstawie akcje. Agent może więc przestrzegać wszystkich reguł, a mimo to – przez odpowiednio spreparowany plik – sprawić, że zaufane narzędzie poza sandboxem wykona polecenie. Inicjatorem całego łańcucha jest prompt injection: złośliwa instrukcja ukryta w pliku README, zgłoszeniu (issue), zależności lub różnicy kodu (diff) zamienia się w lokalną akcję na maszynie programisty.

Pillar Security podzielił siedem odkrytych podatności na cztery ogólne kategorie błędów:

Sandboxy oparte na czarnej liście – nie nadążają za zmianami w systemie operacyjnym.
Konfiguracja przestrzeni roboczej jako kod wykonywalny – pliki konfiguracyjne są traktowane jako skrypty.
„Bezpieczne” listy dozwolonych poleceń – ufają nazwie komendy, nie jej argumentom.
Uprzywilejowane lokalne demony – działają całkowicie poza sandboxem, a agent ma do nich dostęp.

Konkretne luki i ich łatki

Cursor – trzy różne wektory ataku

W środowisku Cursor badacze odkryli kilka poważnych podatności. Pierwsza dotyczy pliku konfiguracyjnego .claude hook – jeśli agent miał kontrolę nad jego treścią, mógł bezpośrednio wykonać kod poza sandboxem. Problem oznaczono jako CVE-2026-48124 i załatano w wersji 3.0.0. Druga luka polegała na możliwości modyfikacji interpretera środowiska wirtualnego (virtualenv) – edytor za pomocą rozszerzenia Pythona uruchamiał go samodzielnie podczas odkrywania zależności. Trzecia podatność wykorzystywała fakt, że metadane Git nie muszą znajdować się w katalogu .git. Agent mógł podmienić plik fsmonitor i w ten sposób wymusić wykonanie kodu, omijając reguły oparte na ścieżkach. Ta ostatnia luka również została załatana w wersji 3.0.0, a numer CVE jest w trakcie nadawania.

Codex CLI – problem z listą dozwolonych komend

W narzędziu OpenAI lista „bezpiecznych” poleceń ufała komendzie git show wyłącznie na podstawie jej nazwy. Tymczasem rzeczywiste wywołanie wcale nie było tylko do odczytu – agent mógł przekazać argumenty powodujące zapis. OpenAI załatało błąd w wersji v0.95.0 i wypłaciło nagrodę za zgłoszenie o wysokim priorytecie. Podobnie jak w przypadku Cursor, numer CVE jest w trakcie przyznawania.

Wspólny problem – demony Docker

Jeden z najciekawszych wniosków dotyczy gniazda Docker. Badacze odkryli, że ta sama luka – dostęp do uprzywilejowanego lokalnego demona poza sandboxem – występuje w trzech narzędziach jednocześnie: Cursor, Codex CLI i Gemini CLI. Agent mógł wykorzystać to gniazdo do uruchomienia kodu poza izolowanym środowiskiem. Obecnie problem został rozwiązany u wszystkich dostawców.

Antigravity i reakcja Google

Dwóm zgłoszeniom dotyczącym narzędzia Antigravity Google nadał niższy priorytet. Chodziło o ominięcie blokady macOS Seatbelt oraz o konfigurację zadań w pliku .vscode jako sposób na przełamanie trybu Secure Mode. Firma uznała je za „inne ważne podatności bezpieczeństwa”, argumentując, że wymagają one socjotechniki lub zaufania do repozytorium, które zawiera pośredni wstrzyk instrukcji (indirect prompt injection). Mimo to badacze z Pillar informują, że zespół Google wysoko ocenił jakość raportów – jeden z nich został opisany jako „wyjątkowo dobrze przygotowany”.

Stary problem w szerszej skali

Sama klasa podatności nie jest nowa. Już w kwietniu firma Cymulate opisała ten sam mechanizm – nazwała go „Configuration-Based Sandbox Escape” – w narzędziach Claude Code, Gemini CLI i Codex CLI. Chodziło o scenariusz, w którym plik zapisany wewnątrz sandboxa uruchamia się na hoście przy następnym starcie aplikacji. Nowością jest skala: ten sam rodzaj błędu pojawia się w czterech produktach od trzech różnych producentów. Dla każdego, kto rozważa używanie agentowych narzędzi do kodowania, jest to sygnał, że problem ma charakter systemowy, a nie przypadkowy.

Rozwiązanie zaproponowane przez Pillar nie polega na dodawaniu kolejnych nazw plików do czarnej listy. Zamiast tego badacze sugerują monitorowanie momentu, w którym zaufane narzędzie lokalne uruchamia coś, co wcześniej zapisał agent. To przesunięcie uwagi z blokowania na obserwację może okazać się skuteczniejsze w walce z tym typem ataku.

Na koniec warto przypomnieć statystyki: zespoły bezpieczeństwa rejestrują 54% udanych ataków, a alarm uruchamiają jedynie w przypadku 14% z nich. Reszta przechodzi przez środowisko niezauważona. Regularne testowanie reguł SIEM i EDR, na przykład za pomocą symulacji naruszeń i ataków, może pomóc w wykryciu tego rodzaju aktywności, zanim wyrządzi szkody.