Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Gemini CLI to otwartoźródłowe narzędzie AI działające w terminalu, które zapewnia dostęp do modeli Gemini bezpośrednio z poziomu wiersza poleceń. Niedawno ujawniona krytyczna podatność pokazała jednak, że integracja agentów AI z lokalnym środowiskiem deweloperskim oraz pipeline’ami CI/CD może tworzyć nową klasę zagrożeń, obejmującą wykonanie kodu poza zakładanym sandboxem oraz kompromitację procesów budowania i dostarczania oprogramowania.
Problem dotyczył błędnego modelu zaufania do bieżącego katalogu roboczego. W efekcie odpowiednio przygotowana konfiguracja mogła zostać automatycznie wczytana i doprowadzić do wykonania poleceń na hoście jeszcze przed aktywacją mechanizmów izolacji.
W skrócie
- Gemini CLI automatycznie ufał bieżącemu katalogowi roboczemu i ładował znalezioną tam konfigurację agenta.
- Złośliwa konfiguracja mogła doprowadzić do wykonania dowolnych poleceń na hoście.
- Do ataku nie było potrzebne prompt injection ani manipulowanie odpowiedziami modelu.
- Luka mogła zostać wykorzystana również w środowiskach CI/CD, zwiększając ryzyko ataków na łańcuch dostaw.
- Problem został załatany zarówno w Gemini CLI, jak i w powiązanej akcji GitHub „run-gemini-cli”.
Kontekst / historia
Podatność została zidentyfikowana przez badaczy z Novee Security. Zwrócili oni uwagę, że narzędzie automatycznie ufało bieżącemu katalogowi projektu i ładowało konfigurację agenta znalezioną w tym środowisku bez dodatkowej weryfikacji, bez zatwierdzenia przez użytkownika oraz bez skutecznego ograniczenia działania do sandboxa.
To istotny sygnał ostrzegawczy dla rynku, ponieważ agenci AI coraz częściej trafiają bezpośrednio do procesów developerskich. Są wykorzystywani przy automatyzacji buildów, testów, analizie kodu i obsłudze workflow, często działając z uprawnieniami zbliżonymi do zaufanego komponentu projektu. W takich warunkach każda luka na styku workspace, agenta i hosta może prowadzić do znacznie poważniejszych skutków niż incydent ograniczony do pojedynczej stacji roboczej.
Analiza techniczna
Rdzeń problemu wynikał z naruszenia granicy zaufania. Gemini CLI traktował bieżący katalog projektu jako zaufane źródło konfiguracji. Jeżeli w workspace znalazł się spreparowany plik konfiguracyjny, narzędzie mogło go załadować automatycznie i wykonać wynikające z niego działania jeszcze przed pełnym uruchomieniem mechanizmów sandboxingu.
Z perspektywy bezpieczeństwa oznaczało to kilka krytycznych błędów architektonicznych:
- niezaufany katalog roboczy był traktowany jak strefa zaufana,
- konfiguracja była interpretowana bez ręcznej akceptacji,
- wykonanie następowało przed pełną izolacją procesu.
W praktyce otwierało to drogę do arbitralnego wykonania poleceń na hoście. Co ważne, nie był to klasyczny przypadek prompt injection, lecz problem związany z kolejnością inicjalizacji, sposobem ładowania konfiguracji oraz nieprawidłowymi założeniami dotyczącymi bezpieczeństwa lokalnego środowiska pracy.
W środowisku CI/CD potencjalny scenariusz ataku mógł wyglądać następująco:
- atakujący umieszcza złośliwą konfigurację w repozytorium lub innym elemencie workspace,
- pipeline uruchamia zadanie korzystające z Gemini CLI albo powiązanej automatyzacji,
- narzędzie ładuje konfigurację przed aktywacją pełnych zabezpieczeń,
- dochodzi do wykonania poleceń na hoście runnera,
- napastnik uzyskuje dostęp do sekretów, tokenów, kodu źródłowego lub mechanizmów dalszej propagacji.
Taki model dobrze wpisuje się w zagrożenia supply chain, ponieważ przejęcie środowiska budowania może umożliwić modyfikację artefaktów, podmianę zależności, wyciek kluczy podpisujących lub dalszy ruch boczny do innych systemów deweloperskich.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem podatności była możliwość wykonania kodu na hoście uruchamiającym agenta. Nawet bez pełnych uprawnień administracyjnych przejęcie kontekstu procesu mogło wystarczyć do odczytania wrażliwych danych dostępnych dla danego workflow.
Ryzyka praktyczne obejmowały:
- kradzież tokenów dostępowych i sekretów CI/CD,
- dostęp do kodu źródłowego oraz poufnych artefaktów,
- ruch boczny do kolejnych systemów i usług wewnętrznych,
- modyfikację procesu build lub release,
- przeprowadzenie ataku na łańcuch dostaw poprzez zainfekowanie produktu końcowego.
Szczególnie niebezpieczne są sytuacje, w których agent AI działa w pipeline z szerokimi uprawnieniami, ma dostęp do zmiennych środowiskowych, kluczy chmurowych, systemów podpisywania lub repozytoriów pakietów. W takim modelu pojedyncza luka w narzędziu automatyzującym może przełożyć się na kompromitację wielu środowisk oraz klientów.
Rekomendacje
Organizacje korzystające z agentów AI w terminalu, pipeline’ach i automatyzacji deweloperskiej powinny potraktować ten incydent jako sygnał do pilnego przeglądu modelu bezpieczeństwa. Narzędzia tego typu należy analizować nie tylko pod kątem jakości modelu czy odporności na prompt injection, ale również z perspektywy klasycznych zasad bezpieczeństwa systemowego.
- Niezwłocznie zaktualizować Gemini CLI oraz powiązane integracje, w tym akcje CI/CD.
- Ograniczyć automatyczne zaufanie do workspace i lokalnych plików konfiguracyjnych.
- Wymusić ręczne zatwierdzanie konfiguracji ładowanej z repozytoriów lub katalogów roboczych.
- Uruchamiać agentów AI w silnie ograniczonych, efemerycznych środowiskach wykonawczych.
- Minimalizować uprawnienia tokenów i sekretów udostępnianych workflow.
- Separować środowiska build, test i release zgodnie z zasadą najmniejszych uprawnień.
- Monitorować nieautoryzowane modyfikacje plików konfiguracyjnych agentów i workflow.
- Wdrożyć detekcję nietypowych poleceń wykonywanych przez narzędzia AI w runnerach oraz stacjach deweloperskich.
- Przeglądać repozytoria pod kątem ukrytych mechanizmów konfiguracji ładowanych automatycznie.
- Traktować agentów AI jak komponent uprzywilejowany, a nie wyłącznie narzędzie pomocnicze.
Dodatkowo warto przeprowadzić threat modeling dla procesów, w których agenci AI mają dostęp do kodu, sekretów i systemów automatyzacji. Kluczowe znaczenie ma ustalenie, kiedy następuje ładowanie konfiguracji, aktywacja sandboxa, dostęp do sieci oraz możliwość wykonywania poleceń systemowych.
Podsumowanie
Luka w Gemini CLI pokazuje, że bezpieczeństwo agentów AI nie sprowadza się wyłącznie do prompt injection czy jakości modelu. Równie istotne są klasyczne błędy architektoniczne, takie jak niewłaściwe granice zaufania, automatyczne ładowanie konfiguracji oraz uruchamianie komponentów przed pełną izolacją.
W środowiskach deweloperskich i CI/CD takie niedopatrzenia mogą bardzo szybko eskalować do incydentów o charakterze supply chain. Dla zespołów bezpieczeństwa to wyraźny sygnał, że narzędzia AI należy traktować jako pełnoprawny element krytycznej powierzchni ataku.
Źródła
- SecurityWeek — https://www.securityweek.com/critical-gemini-cli-flaw-enabled-host-code-execution-supply-chain-attacks/
- Google Gemini CLI patch information — https://github.com/
- Novee Security — https://novee.security/