GhostAction: fałszywy workflow „security audit" trafił do 30 000 repozytoriów

Między 8 a 12 października 2026 roku, ze szczytem 8 i 9 października, kampania kradzieży poświadczeń znana jako GhostAction rozszerzyła się na ponad 30 000 repozytoriów należących do 3000 użytkowników i organizacji na GitHubie, wykorzystując około 1900 przejętych kont. Kampania próbowała wydobyć 3174 sekrety z publicznych repozytoriów i ich procesów CI/CD.

Metoda jest prosta aż do banału. Napastnicy uzyskują prawo zapisu dzięki skradzionym tokenom dostępu osobistego (PAT) lub poświadczeniom zebranym przez infostealery, a następnie wypychają do gałęzi domyślnej każdego dostępnego repozytorium plik workflow o uspokajającej nazwie, najczęściej security-audit.yml lub github_actions_security.yml.

Workflow zbiera sekrety GitHub Actions, do których odwołują się istniejące procesy projektu, i wysyła je na serwer kontrolowany przez napastnika.

GhostAction nie jest zjawiskiem nowym. Badacze GitGuardian, Gaetan Ferry i Guillaume Valadon, śledzą tę kampanię od pierwszego ujawnienia we wrześniu 2025 roku i jej powrót podsumowali bez ozdobników: „Kampania, którą ujawniliśmy we wrześniu 2025 roku, wróciła".

Jedno istotne zastrzeżenie co do skali. GitHub zaczął blokować uruchamianie złośliwego workflow 9 października, więc dwie kolejne fale nie zdołały wydobyć żadnych sekretów. Liczba 30 000 opisuje repozytoria zaatakowane, a nie skutecznie ograbione. Pozostałe ryzyko koncentruje się u wcześniejszych ofiar, które nigdy nie wymieniły swoich sekretów.

Co się wydarzyło

Kampania w trzech falach

Uwagę przyciągnął październikowy skok, ale potwierdzone straty leżą we wrześniowej fali.

Jak to działa, krok po kroku

1. Poświadczenia przychodzą już skradzione. Napastnicy nie włamują się do GitHuba. Używają tokenów PAT lub danych logowania zebranych wcześniej przez infostealery działające na komputerach deweloperów. Na żadnym etapie nie dochodzi do wykorzystania podatności GitHuba.

2. Workflow trafia do każdego repozytorium z prawem zapisu. Korzystając z przejętego konta opiekuna projektu, napastnik dodaje plik do katalogu .github/workflows/. Zaobserwowane opisy commitów są celowo nudne: „Add security audit workflow", „Update security audit workflow" oraz „Add Github Actions Security workflow".

3. Rozpoznanie ustala, które sekrety istnieją. Workflow niczego nie zgaduje. Odczytuje istniejące procesy repozytorium, żeby ustalić, z których nazwanych sekretów Actions projekt faktycznie korzysta, a potem odwołuje się dokładnie do tych nazw.

4. Sekrety są sklejane i wyprowadzane. Workflow buduje ciąg zawierający nazwy i wartości sekretów, po czym wysyła go na zewnętrzny adres. Badacze udokumentowali punkt eksfiltracji pod adresem 193.32.204.199.

Czego szukali

Lista celów odzwierciedla to, co faktycznie przechowują współczesne procesy CI/CD:

• Tokeny repozytoriów pakietów: hasła PyPI, tokeny crates.io, dane publikacyjne npm i innych

• Tokeny dostępu osobistego GitHuba

• Poświadczenia chmurowe, przy czym kolejne wersje ładunku skanowały konkretnie pod kątem kluczy AWS

• Tokeny GitLaba

• Klucze API dostawców AI, kategoria nowsza i stanowiąca bezpośrednią drogę do płatnej mocy obliczeniowej

Najdłuższy ogon ma kradzież danych publikacyjnych. Skradziony token PyPI czy crates.io to nie tylko strata opiekuna projektu. To możliwość opublikowania złośliwej wersji pakietu, od którego zależą inni.

Znani poszkodowani

Dwa przejęte konta opiekunów, kitao i henrywoo, wypchnęły workflow do każdego repozytorium, do którego miały prawo zapisu. Wśród dotkniętych projektów znalazły się kitao/pyxel, mający ponad 18 000 gwiazdek, oraz uber/athenadriver. Socket podał, że aktywność z 8 października objęła 346 repozytoriów powiązanych z tymi dwoma kontami.

Co ograniczyło szkody

Dwie rzeczy, obie warte odnotowania, bo tłumaczą, dlaczego 30 000 repozytoriów nie zamieniło się w 30 000 naruszeń.

GitHub wstrzymał większość uruchomień do zatwierdzenia. Spośród 3669 uruchomień zebranych przez GitGuardian większość została wstrzymana, a nie wykonana. Domyślne zachowanie GitHuba, wymagające zatwierdzenia uruchomień od osób spoza projektu lub działających po raz pierwszy, wykonało tu realną pracę.

GitHub zablokował złośliwy workflow od 9 października. Kolejne fale były już nieskuteczne.

Żadna z tych rzeczy nie pomaga osobom skompromitowanym we wrześniowej fali, gdy eksfiltracja została potwierdzona.

Dlaczego to ma znaczenie

Nie ma czego łatać. Nie wchodzi tu w grę żadna wada oprogramowania. Atak jest w całości konsekwencją ważnych poświadczeń, prawa zapisu oraz systemu CI/CD zaprojektowanego tak, by wykonywać dowolny kod znajdujący się w repozytorium. Zarządzanie podatnościami tego nie rozwiązuje.

Nazwa pliku jest socjotechniką. Plik security-audit.yml w katalogu workflow wygląda jak przejaw staranności. Opiekun projektu rzucający okiem na listę commitów widzi „Add security audit workflow" i odczytuje to jako czyjąś uprzejmość. Oszustwo celuje w etap ludzkiego przeglądu, a nie w mechanizm techniczny.

Infostealery są linią zaopatrzenia. Poświadczenia, które to umożliwiły, zostały wykradzione z komputerów deweloperów przez pospolite złośliwe oprogramowanie, często na długo przed ich wykorzystaniem. Każda stacja robocza dewelopera jest ścieżką dostępu do wszystkich repozytoriów, w których ten deweloper może zapisywać.

Sekrety CI/CD są dziś najcenniejszym łupem. Jeden przejęty proces daje poświadczenia chmurowe, tokeny publikacyjne i klucze API do AI. To infrastruktura produkcyjna, dystrybucja oprogramowania i konto rozliczeniowe w jednym miejscu.

Prawdziwą ekspozycją są sekrety, których nikt nie wymienił. Badacze zwracają uwagę, że utrzymująca się skuteczność kampanii wskazuje na poleganie na sekretach, których po wcześniejszych kompromitacjach nigdy nie zmieniono. Fala z 2025 roku wyprowadziła co najmniej 3325 sekretów. Każdy z nich, jeśli nadal jest ważny, pozostaje użyteczny.

Kogo to dotyczy

• Opiekunów każdego repozytorium, do którego trafił złośliwy workflow od 31 sierpnia 2026 roku.

• Wszystkich skompromitowanych w falach z września 2025 lub września 2026, gdzie eksfiltracja została potwierdzona, a sekrety mogą wciąż działać.

• Forków zainfekowanych repozytoriów, które mogą nieść plik workflow dalej.

• Odbiorców pakietów opublikowanych przez poszkodowanych, jeśli skradziono dane publikacyjne i ich użyto.

• Organizacji, których deweloperzy padli ofiarą infostealerów, co jest warunkiem wstępnym całej kampanii.

• Zespołów przechowujących klucze chmurowe lub klucze do AI jako sekrety Actions, co jest standardową praktyką, a więc grupą bardzo liczną.

Co powinny zrobić organizacje

Sprawdź obecność workflow

1. Przeszukaj wszystkie repozytoria pod kątem plików .github/workflows/security-audit.yml oraz .github/workflows/github_actions_security.yml dodanych 31 sierpnia 2026 roku lub później.

2. Sprawdź historię commitów pod kątem opisów „Add security audit workflow", „Update security audit workflow" oraz „Add Github Actions Security workflow".

3. Przeszukaj wszystkie gałęzie, nie tylko domyślną, oraz sprawdź forki każdego dotkniętego repozytorium.

4. Przejrzyj historię uruchomień workflow pod kątem wykonania tych plików i ustal, czy uruchomienia zostały wstrzymane do zatwierdzenia, czy faktycznie wykonane. Ta różnica decyduje o tym, czy sekrety opuściły organizację.

Jeśli coś znajdziesz, potraktuj repozytorium jako skompromitowane

StepSecurity, Socket i GitGuardian zalecają to samo, a kolejność ma znaczenie:

5. Unieważnij przejęte poświadczenie GitHuba, w tym token PAT użyty do wypchnięcia workflow.

6. Wymień każdy sekret, do którego odwołują się procesy repozytorium. Nie tylko te, które Twoim zdaniem zostały odczytane. Workflow wyliczył je z Twojej istniejącej konfiguracji.

7. Usuń złośliwy workflow ze wszystkich gałęzi oraz z forków, nad którymi masz kontrolę.

8. Sprawdź, do czego te poświadczenia dawały dostęp, zwłaszcza w zakresie kont chmurowych, repozytoriów pakietów i rozliczeń u dostawców AI.

9. Sprawdź repozytoria pakietów pod kątem nieoczekiwanych wydań opublikowanych skradzionymi tokenami.

Ogranicz stałą ekspozycję

10. Traktuj tokeny PAT jako krótkoterminowe. Ustawiaj daty wygaśnięcia, nadawaj wąskie uprawnienia i wybieraj tokeny o precyzyjnym zakresie zamiast klasycznych.

11. Wymagaj zatwierdzania uruchomień workflow od osób spoza projektu i działających po raz pierwszy. Domyślne ustawienia GitHuba stępiły tę kampanię, więc warto je zweryfikować, a nie zakładać.

12. Chroń gałąź domyślną, tak aby pliki workflow nie mogły być dodane bez przeglądu. Reguła ochrony gałęzi wymagająca recenzji zmian w .github/workflows/ zatrzymałaby ten atak na etapie wypchnięcia.

13. Używaj federacji OIDC zamiast długowiecznych poświadczeń chmurowych tam, gdzie dostawca na to pozwala, żeby nie było statycznego sekretu do kradzieży.

14. Wymieniaj sekrety CI/CD cyklicznie, a nie wyłącznie po incydencie. Trwałość tej kampanii opiera się na sekretach, których nikt nigdy nie zmienił.

15. Monitoruj stacje deweloperskie pod kątem infostealerów i traktuj każdą taką infekcję jako incydent tożsamościowy: zakładaj, że każdy token na tej maszynie jest skompromitowany, i unieważniaj go.

Podsumowanie

Napastnicy nie napisali exploita i nie znaleźli błędu. Użyli haseł, które ktoś inny już wcześniej ukradł, dodali plik o budzącej zaufanie nazwie i pozwolili automatyzacji GitHuba wykonać całą pracę. Cała kampania jest dowodem na to, że proces CI/CD to usługa zdalnego uruchamiania kodu, którą świadomie skierowałeś na własne sekrety.

Lekcja: w CI/CD prawo zapisu do repozytorium jest równoznaczne z prawem odczytu każdego sekretu, z którego to repozytorium korzysta. Większość zespołów tak o tym nie myśli. Uprawnienia do repozytorium traktuje się jako kontrolę nad kodem, a sekrety jako chronione osobno. Plik workflow znosi to rozróżnienie, bo każdy, kto może dodać workflow, może poprosić o sekrety po nazwie.

Druga lekcja dotyczy rotacji. GitHub zablokował październikowe fale, a większość uruchomień wstrzymano do zatwierdzenia, więc nagłówkowa liczba 30 000 repozytoriów znacząco zawyża rzeczywiste straty. Ale fala z września 2025 roku wyprowadziła co najmniej 3325 sekretów, a dalsza skuteczność kampanii sugeruje, że wielu z nich nigdy nie zmieniono. Skradzione poświadczenie, którego nikt nie wymienia, nie wygasa. Ono po prostu czeka.

Dwie rzeczy warte zrobienia dziś: przeszukaj swoją organizację pod kątem tych dwóch nazw plików we wszystkich gałęziach oraz wybierz losowo jeden sekret CI/CD i ustal, kiedy był ostatnio wymieniany.