Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Cordyceps to określenie nowej klasy zagrożeń wymierzonych w procesy CI/CD, w których atakujący wykorzystuje zaufanie do automatycznych workflow uruchamianych wokół pull requestów. Nie chodzi tu o pojedynczą podatność typu CVE, lecz o błędne połączenie automatyzacji, uprawnień i danych pochodzących od nieufnych kontrybutorów.
W praktyce oznacza to, że zwykły pull request, komentarz lub inna interakcja z procesem developerskim może stać się punktem wejścia do wykonania nieautoryzowanego kodu, przejęcia sekretów lub uzyskania dostępu do zasobów powiązanych z pipeline’em.
W skrócie
Cordyceps opisuje scenariusze, w których workflow CI/CD uruchamiane w kontekście pull requestów otrzymują zbyt szerokie uprawnienia albo przetwarzają nieufne dane tak, jakby były zaufane. Taka sytuacja może prowadzić do eskalacji uprawnień, fałszowania wyników testów, publikacji złośliwych artefaktów i naruszenia integralności całego łańcucha dostaw oprogramowania.
- atak może rozpocząć się od złośliwego pull requestu lub komentarza,
- celem mogą być tokeny CI, sekrety, klucze podpisujące i konta chmurowe,
- skutkiem może być kompromitacja procesu build, testów i release,
- problem wynika z architektury workflow, a nie z pojedynczego błędu w komponencie.
Kontekst / historia
Opis Cordyceps został ujawniony 23 czerwca 2026 roku przez badacza Elada Megeda z firmy Novee. Publikacja zwróciła uwagę na ryzyka obecne w modelu współpracy open source, gdzie zewnętrzne pull requesty są naturalnym elementem procesu wytwarzania oprogramowania.
Według ujawnionych informacji problem dotyczył setek publicznych repozytoriów, w tym projektów i organizacji o wysokiej rozpoznawalności. Wśród przykładów wymieniano workflow związane z Microsoft Azure Sentinel, Google AI Agent Development Kit, Apache Doris, Cloudflare Workers SDK oraz narzędziem Black rozwijanym przez Python Software Foundation.
Istotnym elementem tła jest też szybki wzrost wykorzystania generatorów i agentów AI do budowy konfiguracji CI/CD. Automatycznie tworzone pliki workflow mogą powielać te same niebezpieczne wzorce, co zwiększa skalę problemu i przyspiesza jego rozprzestrzenianie się między repozytoriami.
Analiza techniczna
Sednem zagrożenia jest naruszenie granicy zaufania między danymi kontrolowanymi przez autora pull requestu a workflow uruchamianym z przywilejami repozytorium bazowego. Poszczególne elementy pipeline mogą działać zgodnie z dokumentacją, ale ich zestawienie tworzy gotową ścieżkę ataku.
Ryzyko pojawia się szczególnie wtedy, gdy pipeline przetwarza metadane pull requestu, komentarze, nazwy branchy, artefakty lub kod z forka jako wejście dla kroków wykonujących polecenia, skrypty albo checkout w kontekście uprzywilejowanym. Jeżeli do tego workflow dysponuje sekretami, tokenami zapisu lub długowiecznymi kluczami, skutki mogą być bardzo poważne.
- nieufne dane wejściowe trafiają do poleceń powłoki lub logiki automatyzacji,
- workflow działa z tokenami o nadmiernym zakresie,
- sekrety są dostępne dla zadań inicjowanych przez zewnętrznych autorów,
- kod z forka jest wykonywany w kontekście zaufanego repozytorium,
- pipeline może publikować artefakty, podpisywać wydania lub zmieniać statusy kontroli jakości.
W opisywanych scenariuszach możliwe było między innymi uruchomienie kodu atakującego po interakcji z pull requestem, kradzież długożyjących kluczy aplikacyjnych, uzyskanie wpływu na zasoby chmurowe oraz manipulowanie zaufanymi sygnałami CI, takimi jak zaliczone testy czy statusy bezpieczeństwa.
Konsekwencje / ryzyko
Skutki Cordyceps wykraczają poza pojedyncze repozytorium. Jeśli pipeline ma dostęp do rejestrów pakietów, kluczy podpisujących, sekretów publikacyjnych lub usług chmurowych, atak może przerodzić się w pełny kompromis łańcucha dostaw oprogramowania.
Z perspektywy bezpieczeństwa szczególnie groźne jest to, że napastnik nie musi przełamywać klasycznych zabezpieczeń aplikacji. Zamiast tego wykorzystuje legalny proces developerski jako kanał uprzywilejowanego wykonania i porusza się w obrębie zaufanej automatyzacji.
- wyciek tokenów i sekretów CI/CD,
- publikacja złośliwych pakietów lub artefaktów,
- modyfikacja procesu build i release,
- obejście polityk branch protection i merge gate,
- podszywanie się pod zaufane boty lub automaty,
- ruch boczny do usług chmurowych zintegrowanych z repozytorium,
- utrata integralności testów i kontroli bezpieczeństwa.
Problem jest szczególnie istotny dla organizacji enterprise, projektów open source i monorepo, gdzie pojedynczy pipeline często ma szeroki dostęp do wielu systemów. Im bardziej rozbudowana automatyzacja, tym większa powierzchnia ataku.
Rekomendacje
Organizacje powinny traktować workflow CI/CD jak kod produkcyjny o wysokiej wrażliwości. Kluczowe jest przeprowadzenie przeglądu architektury zaufania, uprawnień, triggerów i przepływu sekretów we wszystkich procesach uruchamianych przez pull requesty oraz zdarzenia powiązane z forkami.
- zinwentaryzować wszystkie workflow uruchamiane przez pull requesty, komentarze i zdarzenia z forków,
- zidentyfikować miejsca, w których nieufne dane trafiają do kroków wykonujących kod,
- ograniczyć zakres tokenów i sekretów zgodnie z zasadą najmniejszych uprawnień,
- rozdzielić workflow walidacyjne od workflow uprzywilejowanych,
- unikać wykonywania kodu z forków w kontekście posiadającym sekrety lub uprawnienia zapisu,
- wymagać jawnej akceptacji przed uruchomieniem zadań uprzywilejowanych dla nieznanych autorów,
- stosować krótkotrwałe poświadczenia zamiast długożyjących kluczy,
- pinować akcje i zależności do niezmiennych wersji lub identyfikatorów commitów,
- monitorować nietypowe checkouty, zmiany statusów, publikacje artefaktów i dostęp do sekretów,
- objąć pliki YAML i definicje pipeline pełnym code review oraz kontrolami bezpieczeństwa.
Warto również wdrożyć mechanizmy detekcji skupione na nadużyciach CI/CD, a nie wyłącznie na klasycznych podatnościach aplikacyjnych. Analiza kontekstów wykonania, przepływu poświadczeń i zależności między repozytorium, runnerem a systemami zewnętrznymi staje się dziś niezbędna.
Podsumowanie
Cordyceps pokazuje, że współczesne ryzyko supply chain coraz częściej wynika nie z pojedynczego błędu w kodzie, lecz z błędnie zaprojektowanych relacji zaufania w automatyzacji developerskiej. Pull request, który z założenia ma wspierać współpracę, może stać się punktem wejścia do uprzywilejowanego pipeline, jeśli workflow nie został właściwie odseparowany od nieufnych danych wejściowych.
Dla zespołów bezpieczeństwa, DevOps i DevSecOps wniosek jest jednoznaczny: konfiguracje CI/CD wymagają takiego samego poziomu przeglądu, utwardzania i kontroli jak aplikacje produkcyjne. To właśnie one coraz częściej decydują o integralności całego procesu wytwarzania oprogramowania.
Źródła
- https://www.darkreading.com/application-security/cordyceps-malicious-pull-requests-developer-workflows
- https://novee.security/blog/
- https://hivesecurity.gitlab.io/blog/cicd-pipeline-attacks-detect-2026/
- https://hivesecurity.gitlab.io/blog/github-actions-cache-poisoning-supply-chain/
- https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/04/CSA_research_note_github-actions-prt-scan-supply-chain-2026_20260414-csa-styled.pdf