Ponad 5500 repozytoriów GitHub zainfekowanych. Jak działa atak na łańcuch dostaw Megalodon

W połowie maja 2026 roku bezpieczeństwo ekosystemu open source otrzymało kolejny mocny cios. Badacze z firmy SafeDep odkryli kampanię nazwaną Megalodon, w wyniku której złośliwe commity trafiły do ponad 5500 repozytoriów na GitHubie. Atak wymierzony był przede wszystkim w programistów i firmy korzystające z publicznie dostępnego kodu – i pokazuje, jak łatwo może dojść do skażenia łańcucha dostaw oprogramowania.

Co istotne, kampania nie wymagała przejęcia kont na platformie npm ani GitHub. Wystarczyło, że Cyberprzestępcy wykorzystali automatyzację i luki w sposobie, w jaki zespoły zarządzają swoimi repozytoriami. Dla polskich programistów i firm utrzymujących własne projekty open source to sygnał, że dotychczasowe nawyki związane z bezpieczeństwem kodu mogą być niewystarczające.

Jak działał Megalodon. Automatyzacja na masową skalę

Według raportu SecurityWeek opisującego ustalenia SafeDep, atak został przeprowadzony w ciągu zaledwie sześciu godzin – od około 11:36 do 17:48 UTC 18 maja 2026 roku. W tym czasie sprawcy wysłali łącznie 5718 złośliwych commitów do 5561 różnych repozytoriów. Atakujący posłużyli się dwoma adresami e-mail, które powiązano z kontem o nazwie „build-bot”.

Szkodliwe commity modyfikowały pliki konfiguracyjne GitHub Actions. SafeDep wyjaśnia, że atakujący wstrzyknęli do repozytoriów dwa rodzaje payloadów. Pierwszy dodawał nowy workflow uruchamiany przy każdym pushu i pull requeście. Drugi zastępował istniejące workflowi, tworząc ukryte backdoory. „Workflow ‘workflow_dispatch’ był wyłączony z reguł antyrekurencyjnych GitHuba”, co pozwalało atakującym na późniejsze wywołanie backdoora przez API przy użyciu skradzionych tokenów.

Co kradli atakujący. Nie tylko kod źródłowy

Po uruchomieniu na maszynach ofiar złośliwy workflow zbierał szeroki wachlarz danych uwierzytelniających. SafeDep wymienia m.in. zmienne środowiskowe CI, credentiale AWS, tokeny dostępu GCP i Azure, klucze SSH, konfiguracje Dockera i Kubernetesa, tokeny API, stringi połączeń do baz danych oraz tokeny GitHub Actions i GitLab CI/CD. Krótko: atakujący przejmowali wszystko, co pozwalało im na dalsze poruszanie się w infrastrukturze ofiary.

Kampania Megalodon została wykryta, gdy SafeDep natknął się na zainfekowane wersje pakietu Tiledesk – otwartej platformy do czatu na żywo i chatbotów. „Ten sam kont npm, eljohnny, opublikował zarówno czystą wersję 2.18.5, jak i skompromitowane wersje. Atakujący nigdy nie dotknął konta npm. Skompromitowali repozytorium GitHub, a opiekun pakietu opublikował kod z zatrutego źródła, nie zdając sobie z tego sprawy” – tłumaczy SafeDep.

Konsekwencje dla polskich zespołów programistycznych

Choć kampania Megalodon dotknęła przede wszystkim repozytoria anglojęzyczne, jej mechanizm jest uniwersalny. Każdy polski zespół, który utrzymuje publiczne repozytorium na GitHubie i korzysta z GitHub Actions, powinien potraktować to jako ostrzeżenie. Atakujący nie przejmują kont – wykorzystują automatyzację i zaufanie do popularnych narzędzi CI/CD.

W odpowiedzi na podobne zagrożenia, npm unieważniło wszystkie tokeny dostępu z uprawnieniami do zapisu, które omijały uwierzytelnianie dwuskładnikowe. Jednak, jak zauważa firma Ox Security, „to powinno zapobiec przejmowaniu kont, ale nie rozwiązuje podstawowego problemu, a złośliwy kod będzie nadal rozprzestrzeniał się przez skompromitowane repozytoria”.

Jak się bronić przed atakami na łańcuch dostaw

Dla administratorów repozytoriów i programistów kluczowe są trzy obszary. Po pierwsze, ograniczenie uprawnień tokenów i kluczy używanych w GitHub Actions do niezbędnego minimum. Po drugie, regularne przeglądanie commitów i workflowów pod kątem podejrzanych zmian – zwłaszcza tych pochodzących od nieznanych autorów. Po trzecie, wdrożenie mechanizmów weryfikacji integralności kodu przed publikacją pakietów, na przykład przez lokalne budowanie z zaufanego źródła.

Bezpieczeństwo łańcucha dostaw oprogramowania to dziś jedno z największych wyzwań. Megalodon pokazuje, że skala ataku może być ogromna, a czas reakcji liczony w godzinach. Warto o tym pamiętać, zanim kolejny commit trafi do repozytorium produkcyjnego.

Opisana kampania to kolejny argument za tym, by traktować każde publiczne repozytorium jako potencjalne źródło zagrożenia. Nie chodzi o paraliż, ale o świadome zarządzanie ryzykiem – i o to, by nigdy nie ufać kodowi na ślepo.