Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Google załatało podatność w agentowym środowisku programistycznym Antigravity IDE, która mogła prowadzić do wykonania dowolnego kodu w wyniku ataku typu prompt injection. Problem wynikał z połączenia dwóch mechanizmów: możliwości tworzenia plików przez agenta oraz niewystarczającej walidacji danych wejściowych przekazywanych do natywnego narzędzia wyszukiwania plików.
W praktyce oznaczało to, że odpowiednio spreparowane dane mogły skłonić system do uruchomienia poleceń poza przewidzianym scenariuszem użycia. To kolejny przykład, że w środowiskach AI dla programistów granica między danymi a instrukcjami wykonawczymi bywa niebezpiecznie cienka.
W skrócie
- Podatność w Antigravity IDE umożliwiała obejście mechanizmów ochronnych i prowadziła do wykonania kodu.
- Źródłem problemu była nieprawidłowa sanitacja parametru przekazywanego do narzędzia
find_by_name, które wykorzystywało programfd. - Atakujący mógł najpierw doprowadzić do utworzenia złośliwego pliku, a następnie uruchomić go przez spreparowane wywołanie wyszukiwania.
- Scenariusz mógł zostać aktywowany również pośrednio, na przykład przez ukryte instrukcje osadzone w plikach pobranych z niezaufanego źródła.
- Problem zgłoszono odpowiedzialnie 7 stycznia 2026 roku, a poprawka została wdrożona 28 lutego 2026 roku.
Kontekst / historia
Rosnąca popularność agentowych narzędzi deweloperskich zmienia model ryzyka w cyberbezpieczeństwie. W tradycyjnym IDE użytkownik samodzielnie wykonuje operacje i interpretuje wyniki, natomiast w środowiskach wspieranych przez AI część działań przejmuje autonomiczny agent analizujący polecenia, pliki projektowe, komentarze, dokumentację czy zawartość repozytoriów.
Taka zmiana sprawia, że prompt injection przestaje być problemem czysto koncepcyjnym. Wystarczy dostarczyć treść, którą agent potraktuje jak instrukcję operacyjną. W przypadku Antigravity IDE luka dobrze wpisuje się w szerszy trend zagrożeń związanych z narzędziami AI dla programistów, gdzie błędna separacja danych od poleceń może prowadzić do realnej eskalacji skutków incydentu.
Analiza techniczna
Rdzeniem problemu była logika narzędzia find_by_name, przeznaczonego do wyszukiwania plików i katalogów według wzorca. Parametr odpowiedzialny za wzorzec nie był dostatecznie rygorystycznie walidowany przed przekazaniem do niższej warstwy wykonawczej. Zamiast ograniczać wejście do bezpiecznego formatu, system przekazywał je dalej do programu fd, otwierając drogę do nadużycia opcji wiersza poleceń.
Badacze zwrócili uwagę na szczególne znaczenie przełącznika -X, który umożliwia wykonywanie poleceń wsadowych na dopasowanych plikach. W efekcie semantyka zwykłego wyszukiwania mogła zostać przekształcona w mechanizm uruchamiania wskazanego programu względem znalezionych obiektów. Jeśli agent wcześniej utworzył plik zawierający złośliwy skrypt, kolejne spreparowane wywołanie wyszukiwania mogło doprowadzić do jego uruchomienia.
Istotne było również to, kiedy dokładnie egzekwowano zabezpieczenia. Z opisu podatności wynika, że wywołanie find_by_name następowało przed pełnym narzuceniem ograniczeń Strict Mode. Ten tryb miał ograniczać dostęp sieciowy, blokować zapisy poza obszarem roboczym oraz wymuszać uruchamianie poleceń w kontekście piaskownicy. Ponieważ jednak podatny mechanizm był traktowany jako natywne narzędzie, możliwe stało się obejście części założeń modelu ochrony.
Szczególnie niebezpieczny był scenariusz pośredniego prompt injection. Użytkownik nie musiał świadomie uruchamiać podejrzanego polecenia. Wystarczało pobranie pliku z niezaufanego źródła, zawierającego ukryte komentarze lub instrukcje skierowane do agenta AI. Jeśli taki artefakt został przetworzony w normalnym workflow deweloperskim, agent mógł samodzielnie przygotować i aktywować złośliwy łańcuch działań.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem podatności było ryzyko zdalnego wykonania kodu w kontekście pracy dewelopera lub środowiska roboczego obsługiwanego przez agenta. Taki incydent może prowadzić do kradzieży sekretów, modyfikacji kodu źródłowego, osadzenia trwałych mechanizmów dostępu, a także do kompromitacji pipeline’ów CI/CD.
W organizacjach intensywnie korzystających z narzędzi AI ryzyko nie kończy się na pojedynczej stacji roboczej. Agent często posiada dostęp do repozytoriów, tokenów, kluczy API, konfiguracji chmurowych i innych wrażliwych zasobów. To oznacza, że lokalna z pozoru podatność w narzędziu deweloperskim może stać się punktem wejścia do szerszego ataku na łańcuch dostaw oprogramowania.
Dodatkowym zagrożeniem jest fałszywe poczucie bezpieczeństwa wynikające z obecności trybu restrykcyjnego. Jeżeli zabezpieczenia są egzekwowane dopiero po uruchomieniu części logiki narzędziowej, napastnik może wykorzystać właśnie ten etap przedkontrolny. Wniosek jest prosty: bezpieczeństwo agentów AI musi obejmować pełną walidację wejścia i ścisłe rozdzielenie instrukcji od nieufnej treści.
Rekomendacje
Organizacje korzystające z agentowych IDE powinny traktować wszystkie dane pochodzące z repozytoriów, komentarzy, zgłoszeń, dokumentacji i importowanych plików jako potencjalnie nieufne. Mechanizmy AI muszą być projektowane tak, aby takie treści nie mogły zmieniać logiki wykonania narzędzi ani wpływać na uruchamianie poleceń systemowych.
Kluczowe znaczenie ma ścisła walidacja parametrów przekazywanych do narzędzi systemowych. Należy całkowicie blokować możliwość przekazywania opcji wykonawczych tam, gdzie oczekiwany jest jedynie pasywny wzorzec wyszukiwania. Bezpieczne podejście obejmuje stosowanie list dozwolonych wartości, jawnego escapingu argumentów oraz twardej separacji danych od parametrów sterujących.
- ograniczenie uprawnień agentów AI do absolutnego minimum,
- odseparowanie środowisk deweloperskich od sekretów produkcyjnych,
- stosowanie piaskownic z silną izolacją procesów i systemu plików,
- monitorowanie wywołań narzędzi lokalnych oraz nietypowych procesów potomnych,
- blokowanie automatycznego wykonywania działań wysokiego ryzyka bez dodatkowej autoryzacji człowieka,
- analizę plików zewnętrznych pod kątem ukrytych instrukcji kierowanych do modeli.
Z perspektywy operacyjnej warto także przeprowadzić przegląd logów i telemetryki pod kątem anomalii związanych z wyszukiwaniem plików, tworzeniem skryptów pomocniczych oraz nietypowym uruchamianiem interpreterów powłoki. Zespoły AppSec i DevSecOps powinny rozszerzyć modele zagrożeń o scenariusze prompt injection oraz nadużycia natywnych narzędzi udostępnianych agentom.
Podsumowanie
Luka w Antigravity IDE pokazuje, że bezpieczeństwo agentowych narzędzi programistycznych zależy nie tylko od izolacji środowiska, ale przede wszystkim od poprawnej walidacji wejścia i kontroli przepływu instrukcji. W tym przypadku połączenie dozwolonego tworzenia plików z możliwością manipulacji parametrem wyszukiwania doprowadziło do pełnego łańcucha wykonania kodu.
To kolejny sygnał, że prompt injection staje się praktycznym wektorem ataku na środowiska deweloperskie. Dla organizacji oznacza to konieczność traktowania agentów AI jak uprzywilejowanych komponentów wykonawczych, które wymagają co najmniej tak samo rygorystycznego podejścia do bezpieczeństwa jak klasyczne narzędzia automatyzacji.
Źródła
- The Hacker News — Google Patches Antigravity IDE Flaw Enabling Prompt Injection Code Execution — https://thehackernews.com/2026/04/google-patches-antigravity-ide-flaw.html
- Pillar Security — analiza podatności Antigravity IDE — https://www.pillar.security/blog/antigravity-prompt-injection
- Google — dokumentacja Antigravity Strict Mode — https://antigravity.google