Pisaliśmy o Comment and Control — badacz Aonan Guan pokazał że Gemini CLI w GitHub Actions jest podatny na wstrzyknięcie przez tytuły zgłoszeń i komentarze. Google odpowiedział że to "znany problem", wypłacił nagrodę i nie opublikował żadnego ostrzeżenia.
27 kwietnia Google wydał pilną aktualizację bezpieczeństwa dla Gemini CLI. Identyfikator GHSA-wpqr-6v78-jr5g. Zdalne wykonanie kodu w potokami CI/CD. Odkryli ją Elad Meged z Novee Security i Dan Lisichkin z Pillar Security — przez GitHub Vulnerability Rewards Program.
To jest ten sam Gemini CLI. Ta sama klasa problemu. Nowi badacze, nowe szczegóły, tym razem z łatką.
Dwa błędy, jeden scenariusz
Podatność składa się z dwóch powiązanych słabości, które razem tworzą krytyczny wektor ataku w środowiskach automatycznych.
Pierwsza: nieprawidłowa obsługa zaufania do przestrzeni roboczej w trybie bezinterakcyjnym. Gdy Gemini CLI działa w środowisku headless — tak jak w GitHub Actions, bez użytkownika przy klawiaturze — automatycznie ufał bieżącemu katalogowi roboczemu bez żadnej weryfikacji. Oznaczało to że narzędzie ładowało pliki konfiguracyjne i zmienne środowiskowe z katalogu .gemini/ bez wyraźnego zatwierdzenia. Atakujący który mógł wpłynąć na zawartość tego katalogu — przez złośliwy pull request od zewnętrznego kontrybutora — mógł wstrzyknąć złośliwe zmienne środowiskowe wykonywane przez agenta.
Druga: tryb --yolo. Nazwa mówi wiele o założeniach projektowych. Tryb zaprojektowany do szybkiego wykonywania bez pytania o potwierdzenie każdego kroku ignorował szczegółowe listy dozwolonych narzędzi. Zamiast wykonywać tylko narzędzia z listy, wykonywał każde polecenie które pojawiło się w kontekście — co w połączeniu z wstrzyknięciem przez prompt pozwalało na uruchomienie dowolnego polecenia systemowego.
Razem: atakujący otwiera pull request ze złośliwą zawartością, potok CI/CD automatycznie uruchamia Gemini CLI w trybie --yolo na tej zawartości, agent ładuje złośliwą konfigurację z katalogu .gemini/ i wykonuje wstrzyknięte polecenia. Bez interakcji użytkownika, bez podwyższonych uprawnień, bez żadnego ostrzeżenia w dziennikach które wyglądałoby podejrzanie.
Łącznik z Comment and Control
W wpisie o Comment and Control opisywaliśmy jak Guan w kilku krokach wyciągnął klucz API Gemini przez tytuł zgłoszenia na GitHubie. Google wtedy odpowiedział że to "znany problem" i nie opublikował żadnego CVE ani publicznego ostrzeżenia dla użytkowników.
GHSA-wpqr-6v78-jr5g jest w tej samej rodzinie — niezaufane wejście do agenta AI z dostępem do poleceń systemowych i sekretów środowiskowych. Różnica jest w mechanizmie: Comment and Control exploitował brak sanityzacji w przepływie obsługi komentarzy. Ta podatność exploituje automatyczne zaufanie do przestrzeni roboczej w trybie headless i brak wymuszania list dozwolonych narzędzi w trybie --yolo.
Dwa odkrycia, ta sama platforma, ta sama klasa strukturalnego problemu: agent AI w potoku CI/CD przetwarza niezaufane wejście i ma jednocześnie dostęp do poleceń systemowych i sekretów środowiskowych. Jak ujmuje to Cyber Security News: "gdy automatyzacja, obsługa promptów i dostęp do powłoki spotykają się z niezaufanym wejściem, małe luki w politykach szybko stają się krytycznymi ścieżkami ataku."
Co Google zmienił
Łatka fundamentalnie zmienia sposób w jaki Gemini CLI obsługuje zaufanie w środowiskach automatycznych. Tryb headless jest teraz wyrównany z trybem interaktywnym: wymaga jawnej konfiguracji zaufania przed przetworzeniem jakichkolwiek danych ze przestrzeni roboczej. Automatyczne zaufanie do bieżącego katalogu jest wyłączone — agent traktuje przestrzeń roboczą jako niezaufaną dopóki operator explicite nie powie inaczej.
To jest zmiana przełamująca kompatybilność wsteczną — Google oznaczył ją jako "breaking security change". Przepływy pracy które polegały na automatycznym zaufaniu przestają działać po aktualizacji bez dodania jawnej konfiguracji. Dla organizacji które chcą dalej używać Gemini CLI w potokami CI/CD: konieczna jest aktualizacja do wersji @google/gemini-cli@0.39.1 lub 0.40.0-preview.3, aktualizacja akcji GitHub run-gemini-cli do wersji v0.1.22 lub nowszej, oraz dodanie zmiennej środowiskowej zaufania do przestrzeni roboczej dla przepływów działających na wewnętrznych zaufanych danych wejściowych.
Dla przepływów przetwarzających zewnętrzne wejścia — pull requesty od zewnętrznych kontrybutorów, treści zgłoszeń od publicznych użytkowników — Google rekomenduje ścisłe listy dozwolonych narzędzi i ostrożny przegląd jakie polecenia mogą być wykonywane. Tryb --yolo w potoku przetwarzającym publiczne wejścia powinien być traktowany jako wektor ataku, nie jako wygodny skrót.
Szerszy wzorzec
Ta podatność i Comment and Control razem opisują architektoniczną pułapkę w projektowaniu narzędzi AI dla środowisk deweloperskich: narzędzie potrzebuje dostępu do systemu plików, zmiennych środowiskowych i poleceń systemowych żeby być użyteczne. Jednocześnie jest projektowane żeby działać automatycznie na wejściach z zewnętrznych źródeł — bo to jest istota automatyzacji CI/CD.
Te dwa wymagania są ze sobą w naturalnym napięciu. Każde narzędzie które je łączy bez starannej separacji niezaufanego wejścia od uprzywilejowanego kontekstu wykonania ma tę samą strukturalną podatność — niezależnie od tego czy nazywa się Gemini CLI, Claude Code, Copilot czy cokolwiek innego.
Pisaliśmy że Comment and Control dotyczy każdego agenta który przetwarza niezaufane wejście mając jednocześnie dostęp do narzędzi i sekretów — Jira, Confluence, Slack, e-mail. GHSA-wpqr-6v78-jr5g potwierdza ten wniosek konkretnym przypadkiem i konkretną łatką.
Łatka jest dostępna. Tryb --yolo w potoku przetwarzającym publiczne wejścia — nie.
Źródła
Cybersecurity News — szczegóły techniczne obu wektorów eksploitacji i wersje z łatką: https://cybersecuritynews.com/gemini-cli-rce-vulnerability/
GBHackers — analiza trybu headless i mechanizmu automatycznego zaufania: https://gbhackers.com/critical-gemini-cli-flaw/
Cyberpress — opis scenariusza ataku przez pull request od zewnętrznego kontrybutora: https://cyberpress.org/gemini-cli-vulnerability-2/
GitHub — rejestr zmian Gemini CLI z poprawką bezpieczeństwa: https://github.com/google-gemini/gemini-cli/releases
