Początek cyberataku, który przeszedł niezauważony
Kiedy pod koniec listopada 2024 roku jeden z opiekunów narzędzia SpotBugs wprowadzał swój osobisty token dostępu do procesu automatyzacji CI, nie podejrzewał, że uruchamia właśnie mechanizm, który kilka miesięcy później zagrozi integralności tysięcy repozytoriów. Skradziony token — PAT — został pozyskany przez cyberprzestępcę za pomocą luk w procesie „pull_request_target”. Wystarczyło jedno złośliwe żądanie ściągnięcia kodu z fałszywego konta, by zdobyć dostęp do wnętrza projektu. To był dopiero początek. Na początku grudnia przestępca zdobył token, a kilka miesięcy później — 11 marca 2025 — wykorzystał go, by wprowadzić fikcyjne konto do projektu SpotBugs. To konto wypchnęło złośliwy workflow GitHub Actions, który umożliwił przechwycenie kolejnego tokena — tym razem opiekuna projektu Reviewdog. Na tym etapie cyberprzestępca był już w stanie podmienić popularny tag „v1” w repozytorium Reviewdog na swoją wersję – ze złośliwym kodem. Efekt? Każdy, kto korzystał z tej akcji, nieświadomie uruchamiał mechanizm, który wypisywał sekrety z systemów CI/CD do logów. Dane były zbierane i mogły być dalej wykorzystywane.
Od SpotBugs do Coinbase – droga skażonego kodu
Przez kolejne dni skażony kod rozprzestrzeniał się po GitHubie. Choć mógł trafić do nawet 23 tysięcy repozytoriów, według najnowszych ustaleń do rzeczywistego ujawnienia danych doszło w 218 z nich. Ofiary nie były przypadkowe — wśród potencjalnych celów znalazła się także giełda kryptowalut Coinbase. W ich przypadku złośliwy komponent został zaciągnięty 14 marca 2025 roku. Na szczęście system zareagował błyskawicznie – nie doszło do kompromitacji danych, a workflow został usunięty. Dopiero teraz, po analizie przeprowadzonej przez ekspertów z Unit 42 (Palo Alto Networks), rysuje się pełny obraz zdarzeń. Atak był przemyślany, rozciągnięty w czasie i perfekcyjnie zsynchronizowany. Początkowo sądzono, że incydent miał charakter jednorazowy. Okazuje się jednak, że już w listopadzie rozpoczęto działania, które doprowadziły do tego, co odkryto dopiero w marcu.
To włamanie uwidacznia poważne słabości w ekosystemie GitHub Actions. Domyślne zaufanie do tagów, brak jednoznacznego przypinania ich do konkretnych commitów oraz szerokie uprawnienia w przepływach „pull_request_target” stwarzają pole do działań sabotażowych. W przypadku tego incydentu wystarczyło jedno nieuważne działanie, by stworzyć łańcuch infekcji między repozytoriami, które nie powinny mieć ze sobą żadnego związku.
Organizacje, które używały naruszonych akcji, muszą działać szybko. Zaleca się natychmiastową rotację wszystkich kluczy API, tokenów i haseł znajdujących się w zmiennych środowiskowych projektów CI/CD. Szczególnej uwagi wymagają logi z okresu od 10 do 14 marca — to właśnie wtedy złośliwe działania mogły zostawić po sobie ślady, nawet jeśli nie doszło do pełnego naruszenia.
