Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
W czerwcu 2026 roku ujawniono poważną podatność w komponencie Claude Code GitHub Action, wykorzystywanym do automatyzacji zadań opartych na AI w środowiskach CI/CD. Problem dotyczył zarówno mechanizmu autoryzacji uruchamiania workflow, jak i sposobu przetwarzania nieufnych danych wejściowych pochodzących z publicznych zgłoszeń oraz pull requestów.
W praktyce luka mogła umożliwić nieautoryzowane wykonanie działań w publicznych repozytoriach, a w określonych konfiguracjach także uzyskanie uprawnień zapisu do kodu, zgłoszeń i plików workflow. To kolejny przykład pokazujący, że integracje AI w procesach deweloperskich należy traktować jak komponenty uprzywilejowane, a nie wyłącznie narzędzia wspomagające pracę zespołu.
W skrócie
- Podatność pozwalała obejść logikę zaufania do aktorów uruchamiających workflow.
- Atakujący mógł wykorzystać własną aplikację GitHub podszywającą się pod zaufanego bota.
- Następnie możliwe było przeprowadzenie pośredniego prompt injection wobec agenta AI.
- Celem były poświadczenia środowiskowe używane do pozyskania tokena OIDC i dalszej eskalacji uprawnień.
- Producent usunął problem w wersji 1.0.94 i nowszych.
Kontekst / historia
Claude Code GitHub Action został zaprojektowany jako narzędzie automatyzujące obsługę zgłoszeń, analizę pull requestów, etykietowanie i wykonywanie poleceń w repozytorium. Tego typu rozwiązania zwiększają produktywność zespołów, ale równocześnie rozszerzają powierzchnię ataku, ponieważ model AI pracuje na treściach dostarczanych przez użytkowników i działa w kontekście środowiska CI/CD.
Problem został zgłoszony producentowi przez badacza bezpieczeństwa RyotaK z GMO Flatt Security na początku 2026 roku. Analiza wykazała, że nie chodziło o pojedynczy błąd implementacyjny, lecz o kombinację kilku ryzykownych założeń: zbyt szerokich uprawnień workflow, nadmiernego zaufania do określonych typów aktorów oraz niewystarczającej izolacji danych wejściowych od instrukcji sterujących agentem AI.
Incydent wpisuje się w szerszy trend zagrożeń związanych z wykorzystaniem agentów AI w procesach deweloperskich. Gdy model ma dostęp do narzędzi wykonawczych, sekretów i interfejsów automatyzacji, prompt injection przestaje być problemem jakościowym, a staje się realnym wektorem naruszenia bezpieczeństwa.
Analiza techniczna
Źródłem podatności była logika kontroli wyzwalania akcji. Workflow miał działać wyłącznie dla użytkowników posiadających odpowiednie uprawnienia do repozytorium, jednak mechanizm dopuszczał aktorów, których nazwa wskazywała na konto bota. Przyjęto błędne założenie, że taki bot automatycznie reprezentuje zaufaną aplikację GitHub zainstalowaną przez administratora.
W praktyce napastnik mógł utworzyć własną aplikację GitHub i użyć jej tokenu do otwarcia zgłoszenia lub pull requestu w publicznym repozytorium ofiary. Workflow błędnie uznawał takie zdarzenie za pochodzące od zaufanego źródła, przez co uruchamiał dalsze przetwarzanie bez właściwej walidacji.
Po obejściu warstwy autoryzacji możliwy był drugi etap ataku, czyli pośrednie prompt injection. Złośliwe instrukcje umieszczone w treści zgłoszenia mogły zostać zinterpretowane przez agenta AI jako wiarygodne polecenia operacyjne. W efekcie model mógł zostać skłoniony do wykonania działań wykraczających poza pierwotny cel workflow.
Najcenniejszym celem były dane środowiskowe procesu wykonawczego. Szczególne znaczenie miały zmienne wykorzystywane do uzyskiwania tokena OIDC, który następnie mógł posłużyć do wymiany na token instalacyjny aplikacji GitHub z uprawnieniami zapisu. Taki scenariusz otwierał drogę do modyfikacji kodu, workflow oraz innych elementów repozytorium.
Badacze wskazali również dodatkowe warianty nadużycia, w tym zbyt liberalne przykładowe konfiguracje workflow oraz możliwość modyfikacji treści istniejącego zgłoszenia między jego uruchomieniem przez zaufanego użytkownika a momentem odczytu przez agenta AI. Pokazuje to, że ryzyko wynikało nie tylko z pojedynczej luki, lecz z całego modelu zaufania zastosowanego w automatyzacji.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją podatności była możliwość przejęcia kontroli nad publicznym repozytorium korzystającym z podatnej konfiguracji. Jeżeli workflow dysponował szerokimi uprawnieniami, napastnik mógł potencjalnie wpływać na kod źródłowy, pliki automatyzacji i proces publikacji zmian.
- modyfikacja kodu źródłowego,
- zmiana plików workflow i mechanizmów CI/CD,
- manipulacja zgłoszeniami oraz pull requestami,
- uzyskanie dostępu do danych pośrednich i wrażliwych informacji środowiskowych,
- budowa łańcucha ataku typu supply chain.
Ryzyko rosło szczególnie wtedy, gdy zaatakowane repozytorium było elementem większego ekosystemu zależności. W takim układzie kompromitacja pojedynczego komponentu mogła prowadzić do dalszej dystrybucji złośliwych zmian do projektów zależnych. To klasyczny scenariusz, w którym lokalne naruszenie bezpieczeństwa przeradza się w problem łańcucha dostaw.
Rekomendacje
Organizacje korzystające z Claude Code GitHub Action powinny niezwłocznie przejść na wersję 1.0.94 lub nowszą. Sama aktualizacja nie rozwiązuje jednak wszystkich problemów, jeśli podatna pozostaje architektura workflow oraz sposób zarządzania uprawnieniami.
- ograniczyć uprawnienia GitHub Actions zgodnie z zasadą najmniejszych uprawnień,
- blokować uruchamianie wrażliwych workflow przez użytkowników bez uprawnień zapisu,
- nie ufać automatycznie zdarzeniom generowanym przez boty i aplikacje bez dodatkowej walidacji,
- separować nieufne dane wejściowe od instrukcji sterujących przekazywanych agentowi AI,
- ograniczać agentowi dostęp do sekretów, jeśli analizuje treści od zewnętrznych użytkowników,
- minimalizować zestaw dostępnych narzędzi wykonawczych i możliwości publikacji wyników,
- monitorować workflow pod kątem nietypowych odczytów zmiennych środowiskowych, generowania tokenów i zmian w automatyzacji,
- uwzględnić prompt injection w modelu zagrożeń dla każdego agenta AI działającego w CI/CD.
Warto również przejrzeć wszystkie wdrożone szablony i przykładowe konfiguracje. W praktyce to właśnie gotowe workflow są często kopiowane bez pełnej oceny ryzyka i stają się źródłem podatności w środowiskach produkcyjnych.
Podsumowanie
Ujawniona luka w Claude Code GitHub Action pokazuje, że bezpieczeństwo agentów AI w pipeline’ach CI/CD zależy przede wszystkim od poprawnej kontroli uprawnień, rygorystycznego modelu zaufania i odporności na prompt injection. W opisywanym przypadku pojedyncze zgłoszenie mogło stać się punktem wejścia do przejęcia repozytorium, jeśli podatna konfiguracja łączyła zbyt szerokie uprawnienia z błędną walidacją aktora i dostępem do wrażliwych tokenów.
Dla zespołów DevSecOps to wyraźny sygnał ostrzegawczy. Integracje AI należy projektować i audytować tak samo ostrożnie jak każdy uprzywilejowany komponent wykonawczy, ponieważ ich kompromitacja może przełożyć się nie tylko na incydent w pojedynczym repozytorium, ale również na zagrożenie dla całego łańcucha dostaw oprogramowania.