Kampaň wfx-loot využila napadené účty GitHubu k prověřování repozitářů a tam, kde účty měly oprávnění zapisovat, k nasazení kódu určeného ke krádeži tajných údajů z prostředí CI. Jde o prostředí pro automatické sestavování a testování softwaru. Společnost Aikido uvedla, že útočníci použili 4 837 napadených účtů a odeslali testovací pull requesty do 61 764 repozitářů. Podle jejího zveřejněného součtu se škodlivý kód spustil a přihlašovací údaje byly odcizeny nejméně z 1 835 repozitářů.
4
9
Kdy útok probíhal a co jednotlivá čísla znamenají
Aktivita podle zpráv začala 10. listopadu 2026 přibližně ve 12:45 UTC. Jedna zpráva vymezuje období testovacích pull requestů do 11. listopadu 15:00 UTC, tedy zhruba 26 hodin a 15 minut.
6
7 Jde o zaznamenané období testování přístupů, nikoli o potvrzení, že ve stejnou dobu skončilo veškeré spouštění škodlivého kódu nebo pozdější využívání ukradených údajů.
Uvedené počty popisují různé fáze kampaně:
- 4 837 účtů bylo podle zpráv napadeno.
- 61 764 repozitářů obdrželo testovací pull request. To je počet prověřovaných repozitářů, nikoli počet těch, kde se prokazatelně spustil škodlivý kód.
- Nejméně 1 835 repozitářů zahrnula Aikido do svého zveřejněného součtu spuštění škodlivého kódu a odcizených přihlašovacích údajů.
9
Některé dobové zprávy uváděly nižší počet 1 806.
6
10 Dostupné podklady rozdíl nevysvětlují, proto je vhodné oba počty chápat jako samostatně publikované údaje, nikoli je sčítat. Poskytnuté zprávy nedokládají ani pozdější tvrzení o zhruba 1 970 potvrzených veřejných případech z více než 66 000 cílů.
Jak útočníci ověřovali přístup
Útočníci otevírali pull requesty s názvem docs: dependency audit notes z větví pojmenovaných wfx-docs. Tyto zdánlivě běžné změny dokumentace sloužily jako test: ukázaly, zda napadený účet může do daného repozitáře zapisovat.
3
4
9
Pokud oprávnění stačila, útočníci nasadili do prostředí CI kód, který kradl tajné údaje. Kampaň se opírala o platné ukradené přístupové údaje, nikoli o zranitelnost GitHub Actions.
4
9 Společnost OX Security popsala škodlivý program jako jediný shellový skript o přibližně 1 500 řádcích.
31
V některých případech byly podle zpráv škodlivé změny a záznamy běhu workflow odstraněny, což komplikovalo následné vyšetřování.
1
6 Dostupné informace dokládají obecný postup — test přístupu, spuštění kódu a následný úklid — ne však všechny uváděné způsoby nasazení či názvy commitů u každé jednotlivé infekce.
Jaké údaje byly cílem
Doloženým cílem bylo získat přihlašovací údaje dostupné úlohám CI, včetně tajných údajů GitHub Actions a cloudových přístupů. Zprávy popisují také pokusy získat tokeny pro služby umělé inteligence.
3
9 Analýza OX Security uvádí mezi cíli přihlašovací údaje pro AWS, Azure a Google Cloud.
31 Další zprávy uvádějí, že škodlivý program mohl prohledávat paměť procesů běžících na CI runneru; dostupné podklady ale neukazují, jak často se mu tímto způsobem podařilo něco získat.
17
29
Podle jednoho souhrnu se útočníci pokoušeli rozšířit přístup také změnami důvěryhodnostních politik AWS a přidáváním federovaných přihlašovacích údajů v Azure.
5 Jde o popis hlášeného chování, nikoli o důkaz, že byly změněny všechny zasažené repozitáře nebo cloudové účty. Dostupné důkazy se týkají krádeže přihlašovacích údajů; nedokládají krádež zdrojového kódu ani zákaznických databází.
9
15
Co naznačují dostupné signály — a co z nich vyvozovat nelze
Jedna zpráva uvádí, že při kontrole zůstalo otevřených 92 % z 10 431 testovacích pull requestů odeslaných přes přístup spolupracovníka nebo organizace.
10
19 To naznačuje, že mnoho z nich do té doby nebylo vyřízeno, samo o sobě to ale nedokazuje, že si jich vlastníci repozitářů nebo bezpečnostní týmy nevšimli. Procento se navíc nevztahuje na všechny pull requesty v kampani.
Vyšetřovací příručka uvádí také 173 testovacích pull requestů od 19 účtů, které používaly tokeny přes aplikaci GitHub App společnosti Fly.io. Tento údaj sám o sobě neprokazuje narušení infrastruktury Fly.io ani spuštění škodlivého kódu ve všech repozitářích, kam se tyto tokeny dostaly.
37
Co by měli správci prověřit
Při vyšetřování je důležité rozlišovat mezi prověřeným repozitářem, vloženým škodlivým kódem, jeho spuštěním a odcizením přihlašovacích údajů. Nejde o zaměnitelné závěry.
- Vyhledejte známky testovacích pull requestů. Zkontrolujte pull requesty s názvem
docs: dependency audit notes a větve wfx-docs v repozitářích, do nichž mohly vaše účty zapisovat.
9
- Prověřte záznamy CI a auditu. Zkontrolujte běhy workflow, commity, aktivitu ve větvích i dostupné cloudové záznamy. Chybějící čísla běhů mohou být vodítkem, protože zprávy popisují mazání běhů a logů; samotná mezera však kompromitaci nedokazuje.
1
24
- Zneplatněte podezřelé přístupy. Odvolejte tokeny GitHubu, které mohly být napadeny, a prověřte přístupy uživatelů, spolupracovníků i aplikací GitHub App.
- Vyměňte všechny potenciálně odhalené tajné údaje. Pokud se škodlivý kód spustil, považujte za potenciálně kompromitované všechny tajné údaje a cloudové role dostupné danému workflow — nejen ty, které jsou vidět v dochovaných záznamech.
3
9
- Hledejte změny cloudového přístupu. Prověřte neočekávané úpravy důvěryhodnostních politik AWS, aplikací v Azure a federovaných přihlašovacích údajů i další neoprávněné změny přístupů.
5
- Uchovejte důkazy. Před úklidem uložte dostupné auditní záznamy a logy a v závěrech jasně uveďte, kterou fázi útoku se podařilo doložit.