Atak na łańcuch dostaw GitHub z użyciem AI: kampania „prt-scan” wykorzystuje błędną konfigurację GitHub Actions

securitybeztabu.pl 1 dzień temu

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw systemu coraz częściej koncentrują się nie tylko na samym kodzie, ale również na procesach CI/CD. Najnowsza kampania oznaczona jako „prt-scan” pokazuje, iż błędna konfiguracja GitHub Actions może stać się bezpośrednim wektorem kompromitacji repozytorium, sekretów oraz procesu publikacji pakietów.

Kluczowym elementem nadużycia jest mechanizm pull_request_target, który przy niewłaściwej implementacji może uruchamiać workflow w kontekście głównego repozytorium także dla niezaufanych pull requestów z forków. W praktyce oznacza to ryzyko kradzieży tokenów, enumeracji sekretów i prób przejęcia dalszych etapów pipeline’u.

W skrócie

Kampania „prt-scan” była zautomatyzowaną operacją wymierzoną w projekty korzystające z podatnych workflow opartych o pull_request_target. Atakujący mieli utworzyć ponad 500 złośliwych pull requestów, wykorzystując wiele kont powiązanych z jednym operatorem oraz techniki automatyzacji wspierane przez AI.

Celem były repozytoria GitHub z niebezpieczną konfiguracją Actions.
Ładunki były dopasowywane do stosu technologicznego ofiary.
Potwierdzono kompromitację co najmniej dwóch pakietów npm.
W części incydentów doszło do wycieku krótkotrwałych poświadczeń i innych sekretów CI/CD.

Kontekst / historia

Zagrożenia wobec platform developerskich i narzędzi automatyzacji budowania rosną od kilku lat, jednak kampania „prt-scan” pokazała nowy poziom skali i personalizacji ataku. W centrum problemu znalazł się trigger pull_request_target, od dawna uznawany za funkcję wymagającą szczególnej ostrożności, ponieważ działa w kontekście repozytorium bazowego i może mieć dostęp do sekretów oraz szerszych uprawnień niż standardowy pull_request.

Według ustaleń badaczy aktywność związana z kampanią rozpoczęła się 11 marca 2026 roku i trwała falami do 2–3 kwietnia 2026 roku. Publiczne ujawnienie nastąpiło 2 kwietnia 2026 roku, choć późniejsze analizy wskazały wcześniejsze testy, kolejne iteracje technik i stopniowe zwiększanie skali operacji.

To istotny sygnał dla całego ekosystemu open source. Atak nie był pojedynczym eksperymentem, ale częścią szerszego trendu, w którym przestępcy zaczynają systematycznie eksploatować błędy konfiguracyjne w GitHub Actions jako drogę do naruszenia software supply chain.

Analiza techniczna

Schemat działania był stosunkowo prosty, ale efektywny przy dużej liczbie prób. Operator wyszukiwał repozytoria wykorzystujące pull_request_target, forkując je i tworząc gałęzie o charakterystycznym nazewnictwie. Następnie przygotowywał pull requesty zawierające złośliwe modyfikacje w plikach, które miały wysoką szansę uruchomienia podczas CI.

Wśród wykorzystywanych plików pojawiały się między innymi conftest.py, package.json, Makefile, build.rs oraz elementy konfiguracji workflow. Zmiany były maskowane jako rutynowe poprawki związane z budowaniem, testami lub kompatybilnością projektu, co miało zmniejszyć czujność maintainerów.

Po uruchomieniu workflow złośliwy kod próbował najpierw zebrać zmienne środowiskowe i tokeny dostępne w kontekście pipeline’u. Następnie wykonywał rozpoznanie środowiska, obejmujące enumerację sekretów, workflow i potencjalnych integracji zewnętrznych. W kolejnych etapach malware podejmowało próby tworzenia tymczasowych workflow, obchodzenia kontroli bezpieczeństwa oraz opóźnionej eksfiltracji danych, na przykład przez logi lub komentarze do pull requestów.

Najbardziej niepokojącym elementem kampanii było dopasowywanie ładunku do technologii używanej przez ofiarę. Badacze odnotowali wzorce sugerujące użycie AI lub modeli LLM do automatycznego rozpoznawania języka, frameworka i procesu budowania projektu. Dzięki temu atakujący mogli generować pozornie naturalne, „idiomatyczne” zmiany dla repozytoriów Python, Node.js, Rust czy Go.

Jednocześnie sama operacja nie była perfekcyjna technicznie. W części analizowanych prób pojawiały się błędy logiczne, niewłaściwe założenia dotyczące modelu uprawnień GitHub oraz nietrafione wektory wstrzyknięcia. To ograniczyło skuteczność kampanii, ale nie zredukowało ryzyka do zera. Przy setkach zautomatyzowanych prób choćby niski odsetek powodzenia może prowadzić do realnych kompromitacji.

Konsekwencje / ryzyko

Najważniejszym skutkiem kampanii jest potwierdzenie, iż błędna konfiguracja GitHub Actions może stać się praktycznym punktem wejścia do ataku na łańcuch dostaw. choćby jeżeli część udanych kompromitacji dotyczyła mniejszych projektów, skutki mogą rozlać się dalej przez zależności open source wykorzystywane w innych środowiskach.

Ryzyko ma kilka warstw. Po pierwsze, istnieje możliwość przejęcia krótkotrwałych poświadczeń workflow, które w określonych warunkach pozwalają na dalsze działania w repozytorium lub usługach zewnętrznych. Po drugie, zagrożone są sekrety CI/CD, takie jak tokeny publikacyjne, klucze API, poświadczenia do usług chmurowych czy tokeny wykorzystywane przez platformy wdrożeniowe. Po trzecie, kampanie tego typu zwiększają obciążenie maintainerów i utrudniają ręczną weryfikację pull requestów przy dużej skali ataku.

Dodatkowym problemem jest operacyjne wykorzystanie AI. Automatyzacja obniża próg wejścia dla mniej zaawansowanych aktorów, a jednocześnie zwiększa tempo i adaptacyjność ataków. To oznacza, iż podobne kampanie prawdopodobnie będą się powtarzać, stając się z czasem bardziej precyzyjne i trudniejsze do wykrycia.

Rekomendacje

Organizacje utrzymujące repozytoria na GitHub powinny w pierwszej kolejności przeprowadzić audyt workflow korzystających z pull_request_target. o ile ten mechanizm nie jest absolutnie niezbędny, należy zastąpić go bezpieczniejszymi wzorcami opartymi o pull_request lub ograniczyć jego użycie do ściśle kontrolowanych scenariuszy.

Kluczowe pozostaje wdrożenie zasady minimalnych uprawnień dla GITHUB_TOKEN oraz jawne definiowanie sekcji permissions w workflow. Nie należy dopuszczać do automatycznego wykonywania kodu z niezaufanych forków przy jednoczesnym dostępie do sekretów.

Wymuszanie manualnego zatwierdzania workflow od first-time contributorów.
Ochrona branchy i obowiązkowe review przed uruchomieniem krytycznych zadań.
Stosowanie warunków ścieżkowych ograniczających aktywację workflow.
Separacja sekretów produkcyjnych od pipeline’ów build/test.
Monitorowanie logów workflow pod kątem anomalii i markerów eksfiltracji.
Regularna rotacja tokenów publikacyjnych oraz sekretów CI/CD.
Przegląd historii pull requestów i workflow pod kątem artefaktów kampanii.

Z perspektywy zespołów bezpieczeństwa szczególnie ważne jest wykrywanie repozytoriów, w których pull_request_target współistnieje z wykonywaniem kodu pochodzącego z forka. Taka kombinacja powinna być traktowana jako sygnał wysokiego ryzyka wymagający natychmiastowej korekty.

Podsumowanie

Kampania „prt-scan” pokazuje, iż bezpieczeństwo GitHub Actions i pipeline’ów CI/CD stało się jednym z kluczowych elementów ochrony łańcucha dostaw oprogramowania. Sam wektor ataku nie jest nowy, ale połączenie go z automatyzacją wspieraną przez AI znacząco zwiększa skalę, szybkość i elastyczność działań przeciwnika.

Dla organizacji najważniejszy wniosek jest prosty: ochrona software supply chain nie kończy się na analizie kodu aplikacji. Równie istotne są konfiguracje workflow, model uprawnień, sposób uruchamiania zadań dla niezaufanych kontrybutorów oraz kontrola sekretów wykorzystywanych w procesie budowania i publikacji.