Kampania „Megalodon” na GitHub. Ponad 5,5 tys. repozytoriów zainfekowanych w sześć godzin
Atakujący wstrzyknęli złośliwe workflow GitHub Actions do tysięcy repozytoriów, wykradając sekrety CI/CD i tokeny. Podatne są projekty open source, które używają GitHub Actions do budowania i publikowania pakietów.
W maju 2026 roku badacze z SafeDep wykryli zautomatyzowaną kampanię, którą nazwali „Megalodon”. W ciągu zaledwie sześciu godzin atakujący wypchnęli ponad 5,7 tysiąca złośliwych commitów do ponad 5,5 tysiąca repozytoriów na GitHubie. Celem było wykradanie sekretów CI/CD, tokenów GitHub, poświadczeń chmurowych i kluczy SSH. Incydent pokazuje, jak skutecznie można zaatakować łańcuch dostaw oprogramowania, wykorzystując zaufane mechanizmy automatyzacji.
Jak działał atak?
Atakujący używali jednorazowych kont GitHub z losowymi, ośmioznakowymi nazwami użytkowników. Wstrzykiwali złośliwe workflow GitHub Actions do repozytoriów, podszywając się pod automatyczne narzędzia CI. W commitach używali nazw autorów takich jak „build-bot” czy „ci-bot” oraz komunikatów imitujących rutynowe akcje, na przykład „ci: add build optimization step”.
Jak opisują badacze SafeDep na łamach Sekuraka, wykorzystano dwa warianty payloadu. Wariant masowy (SysDiag) dodawał nowy workflow uruchamiany przy każdym pushu i pull requeście. Drugi, bardziej zaawansowany wariant (Optimize-Build), zastępował istniejący workflow mechanizmem workflow_dispatch, tworząc backdoor, który atakujący mogli uruchomić zdalnie przez API GitHub. Dzięki temu złośliwy kod pozostawał uśpiony i nie uruchamiał się automatycznie.
Ofiary i skala kompromitacji
Wśród zainfekowanych repozytoriów znalazły się projekty związane z platformą Tiledesk – otwartoźródłowym systemem live chat i chatbotów. Atakujący wstrzyknęli złośliwy kod do repozytorium tiledesk-server, a następnie, nie przejmując konta npm, doprowadzili do publikacji zainfekowanych wersji pakietu @tiledesk/tiledesk-server (wersje od 2.18.6 do 2.18.12). Programista publikował kolejne wersje z zainfekowanego źródła, nie zdając sobie sprawy z zagrożenia.
Łącznie, jak informuje SecurityWeek w raporcie o podobnym ataku na Red Hata, w przypadku kampanii Megalodon zidentyfikowano 5561 repozytoriów, które otrzymały złośliwe commity. Pełna lista znajduje się na stronie SafeDep. Atakujący rotowali między czterema nazwami autorów i siedmioma komunikatami commitów, co utrudniało szybkie wykrycie anomalii.
Co wykradał malware?
Złośliwy skrypt bash, zakodowany w base64 i umieszczony w workflow, zbierał zmienne środowiskowe dostępne na runnerze CI/CD. Przechwytywał sekrety wykorzystywane przez pipeline, w tym GITHUB_TOKEN, poświadczenia Docker Hub, a także inne tokeny i klucze dostępowe. Następnie wysyłał je do serwera C2 pod adresem 216.126.225.129. Eksfiltracja następowała przez żądania HTTP z metadanymi identyfikującymi ofiarę.
Badacze z Ox Security, cytowani przez SecurityWeek, zidentyfikowali 210 repozytoriów zawierających skradzione poświadczenia, co sugeruje, że co najmniej tylu programistów zostało zainfekowanych po pobraniu i zainstalowaniu złośliwych wersji pakietów.
Jak się chronić?
Dla twórców oprogramowania kluczowe jest monitorowanie repozytoriów pod kątem nieautoryzowanych commitów. Warto wdrożyć mechanizmy wymagające recenzji kodu i podpisywania commitów. Administratorzy powinni regularnie przeglądać uprawnienia tokenów PAT (Personal Access Token) i ograniczać je do niezbędnego minimum.
Dla użytkowników pakietów npm i innych rejestrów – zawsze sprawdzajcie sumy kontrolne i podpisy cyfrowe publikowanych wersji. Jeśli używacie bibliotek zależnych, warto skanować je narzędziami do analizy składu oprogramowania (SCA).
W razie podejrzenia kompromitacji – natychmiast zrotujcie wszystkie tokeny, klucze API i poświadczenia, które mogły być przechowywane w zmiennych środowiskowych CI/CD. Monitorujcie środowiska pod kątem nietypowych połączeń wychodzących.
Incydent „Megalodon” unaocznia, że ataki na łańcuch dostaw stają się coraz bardziej wyrafinowane i zautomatyzowane. Nie polegają już na przejmowaniu kont, ale na wykorzystaniu zaufanych mechanizmów CI/CD do rozprzestrzeniania malware. To sygnał, że bezpieczeństwo open source wymaga dziś znacznie więcej niż tylko dobrej woli społeczności.
