Wprowadzenie do problemu / definicja
Nowe ustalenia badaczy bezpieczeństwa pokazują, że narzędzia AI wspierające programistów mogą stać się realnym wektorem ataku na środowiska CI/CD. W analizowanych przypadkach nie było wymagane klasyczne przejęcie repozytorium ani uzyskanie bezpośrednich uprawnień do pipeline’u. Wystarczało odpowiednio przygotowane zgłoszenie GitHub Issue lub złośliwe dane wejściowe, aby uruchomić łańcuch prowadzący do wykonania komend, utrwalenia złośliwego stanu albo wycieku sekretów.
Kluczowy problem dotyczy warstwy pośredniczącej między modelem AI a systemem operacyjnym, plikami roboczymi i workflow automatyzacji. To właśnie w tej warstwie błędne założenia dotyczące zaufania do danych, walidacji poleceń i izolacji środowiska mogą otworzyć drogę do ataków supply chain.
W skrócie
- Badacze ujawnili podatności dotyczące narzędzi Claude Code i Gemini CLI używanych w procesach developerskich oraz CI.
- W Gemini CLI najbardziej krytyczny scenariusz umożliwiał wykonanie poleceń na hoście CI jeszcze przed uruchomieniem sandboxa.
- W Claude Code wykazano możliwość eksfiltracji sekretów, w tym kluczy API, z wykorzystaniem kanału bocznego.
- W scenariuszu związanym z Codex problem dotyczył architektury workflow i współdzielonego stanu między etapami jednego joba.
- Dostawcy opublikowali poprawki, mitygacje lub zmiany operacyjne, dlatego aktualizacja i przegląd pipeline’ów są obecnie niezbędne.
Kontekst / historia
Rosnąca popularność agentów AI w DevOps i automatyzacji wytwarzania oprogramowania zwiększa produktywność zespołów, ale jednocześnie rozszerza powierzchnię ataku. Narzędzia tego typu coraz częściej analizują pull requesty, wykonują komendy shell, modyfikują pliki w repozytorium i uczestniczą w automatycznych workflow uruchamianych przez zdarzenia zewnętrzne.
Opisane przypadki dobrze wpisują się w szerszy trend badań nad bezpieczeństwem agentów AI. Problemem nie okazał się sam model językowy, ale sposób, w jaki środowisko wykonawcze interpretuje polecenia, przekazuje dane wejściowe między etapami i egzekwuje polityki bezpieczeństwa. Jeśli niezaufana treść zostanie potraktowana jako bezpieczna na jednym etapie, a następnie użyta z większymi uprawnieniami na kolejnym, ryzyko incydentu rośnie bardzo szybko.
Analiza techniczna
Najpoważniejszy scenariusz dotyczył Gemini CLI. Ujawniona luka opisana jako CVE-2026-12537 miała charakter command injection w mechanizmie uruchamiania kontenera. Według opisu wektor wejściowy prowadził przez spreparowany plik konfiguracyjny w katalogu roboczym, co mogło umożliwić nieuprzywilejowanemu użytkownikowi wykonanie kodu na hoście CI jeszcze przed aktywacją izolacji. To szczególnie niebezpieczne, ponieważ podważa podstawowe założenie, że ryzykowne działania zostaną ograniczone przez sandbox.
W Gemini CLI badacze wskazali również problem z egzekwowaniem listy dozwolonych narzędzi. Mechanizm bezpieczeństwa działał na etapie rejestracji, ale nie był skutecznie wymuszany w czasie faktycznego wykonania. W praktyce mogło to prowadzić do uruchamiania poleceń, które zgodnie z polityką powinny być zablokowane, zwłaszcza w trybach automatycznej akceptacji działań agenta.
W Claude Code ujawniono z kolei CVE-2026-54316. W tym przypadku badacze pokazali kanał boczny pozwalający na eksfiltrację sekretu znak po znaku, wykorzystując publicznie widoczny licznik pobrań w ekosystemie modeli. Dodatkowo opisano problem z analizą i walidacją poleceń, gdzie część składni mogła zostać pominięta przed kontrolą bezpieczeństwa. To otwierało drogę do przeniesienia złośliwych parametrów do wywołań narzędzi deweloperskich i dalszego ich wykonania w kontekście runnera.
Scenariusz związany z Codex nie opierał się na klasycznej luce produktowej, lecz na ryzyku projektowym w workflow. Dwa przebiegi agenta wykonywano w ramach jednego joba i współdzieliły one ten sam checkout repozytorium. W rezultacie wcześniejszy etap mógł zapisać plik z instrukcjami operacyjnymi, który późniejszy etap odczytywał już jako wiarygodne polecenia. Taki model sprzyja atakom typu persistence within job, gdzie złośliwy stan przygotowany wcześniej staje się aktywny dopiero w kolejnej fazie automatyzacji.
Konsekwencje / ryzyko
Konsekwencje takich podatności są poważne dla wszystkich organizacji korzystających z AI w pipeline’ach CI/CD. W skrajnym scenariuszu atakujący może doprowadzić do wykonania kodu na runnerze, wycieku sekretów workflow, przejęcia tokenów CI, kluczy API, zmiennych środowiskowych, artefaktów buildów albo poświadczeń do usług chmurowych.
Szczególnie groźne są przypadki, w których zewnętrzny użytkownik może pośrednio aktywować workflow poprzez issue, komentarz, pull request lub publicznie dostępny plik konfiguracyjny. W takim modelu granica między niezaufanym inputem a logiką wykonawczą staje się bardzo cienka. Jeżeli agent AI ma możliwość uruchamiania komend, zapisu plików lub dostępu do sekretów, nawet drobna luka w warstwie sterującej może przełożyć się na pełnowymiarowy incydent bezpieczeństwa.
Dodatkowym problemem pozostaje wykrywanie takich ataków. Aktywność agenta może wyglądać jak legalna automatyzacja, a wyciek danych może odbywać się przez nietypowe kanały pośrednie. To utrudnia klasycznym narzędziom monitoringu szybkie wykrycie incydentu i zwiększa znaczenie kontroli dedykowanych dla AI-assisted CI/CD.
Rekomendacje
Najważniejszym krokiem jest aktualizacja podatnych komponentów do wersji zawierających poprawki lub wdrożenie oficjalnych mitygacji dostawców. Samo patchowanie nie powinno jednak kończyć procesu zabezpieczania środowiska.
- Przeprowadź przegląd workflow uruchamianych przez issue, komentarze, pull requesty i inne dane pochodzące od użytkowników zewnętrznych.
- Traktuj wszystkie takie dane jako niezaufane i nie przekazuj ich bezpośrednio do uprzywilejowanych kroków automatyzacji.
- Uruchamiaj agentów AI jako ostatni etap joba albo w osobnym, odizolowanym jobie bez dostępu do wrażliwych sekretów.
- Unikaj współdzielenia checkoutu, katalogów roboczych i plików instrukcyjnych między etapami o różnym poziomie zaufania.
- Stosuj zasadę minimalnych uprawnień dla runnerów, tokenów CI i sekretów środowiskowych.
- Ogranicz możliwość wykonywania dowolnych komend shell oraz wymuszaj realnie egzekwowane allowlisty na etapie wykonania.
- Loguj wszystkie działania agenta, zmiany w plikach instrukcyjnych, odwołania do sekretów i nietypowe połączenia wychodzące z runnerów.
- Regularnie testuj pipeline’y AI-assisted pod kątem nadużyć, w tym z użyciem ćwiczeń red team i symulacji ataków.
Podsumowanie
Przypadki dotyczące Claude Code, Gemini CLI i scenariusza z Codex pokazują, że największe ryzyko w narzędziach AI dla programistów często nie wynika z samego modelu, lecz z logiki wykonawczej, izolacji środowiska i błędnego zaufania do danych wejściowych. W praktyce oznacza to, że nawet zwykłe zgłoszenie GitHub Issue może stać się początkiem ścieżki prowadzącej do wycieku sekretów lub wykonania kodu w CI.
Dla zespołów bezpieczeństwa to wyraźny sygnał, że agentów AI należy traktować jak uprzywilejowanych wykonawców kodu. Bez segmentacji workflow, minimalizacji uprawnień, aktualizacji komponentów i ścisłej kontroli niezaufanego inputu wdrażanie AI do CI/CD może generować ryzyko nieproporcjonalne do oczekiwanych korzyści.
Źródła
- The Hacker News – Claude Code and Gemini CLI Flaws Let a GitHub Issue Reach CI Workflow Secrets — https://thehackernews.com/2026/08/claude-code-and-gemini-cli-flaws-let.html
- GitHub Security Advisory – Gemini CLI GitHub Actions fixes — https://github.com/google-gemini/gemini-cli/security
- Anthropic Security Advisory – Claude Code vulnerability information — https://github.com/anthropics/claude-code/security
- NVD – CVE-2026-12537 — https://nvd.nist.gov/vuln/detail/CVE-2026-12537
- NVD – CVE-2026-54316 — https://nvd.nist.gov/vuln/detail/CVE-2026-54316