24 czerwca firma Novee Security ujawniła Cordyceps — systemową klasę podatności w workflow CI/CD, która pozwala dowolnemu nieuwierzytelnionemu użytkownikowi przejąć kontrolę nad repozytoriami niektórych z największych firm świata. Skan około 30 000 najważniejszych repozytoriów wykazał 654 oznaczone jako potencjalnie podatne w jednym przebiegu, a ponad 300 potwierdzono jako w pełni eksploatowalne. Wśród dotkniętych: Microsoft, Google, Apache, Cloudflare i Python Software Foundation. Wszyscy potwierdzili i naprawili.
Nazwa pochodzi od pasożytniczego grzyba, który przejmuje ciała swoich żywicieli — i jest celna, bo Cordyceps nie jest pojedynczym błędem. Jest wzorcem, który najlepsze, najlepiej finansowane zespoły inżynierskie świata powtarzają raz za razem. Założyciel Novee Elad Meged ujął barierę wejścia jednym zdaniem: luka jest eksploatowalna przez dowolnego nieuwierzytelnionego użytkownika — bez członkostwa w organizacji, bez specjalnych uprawnień; darmowe konto wystarczy, by sfałszować zatwierdzenia, wypchnąć kod albo ukraść poświadczenia.
Ale najważniejsze w Cordyceps nie jest to, kto może go wykorzystać. Najważniejszy jest fakt, gdzie luka istnieje — bo to jest dokładnie ten sam mechanizm, który prowadzimy jako wątek od tygodni.
Luka, która istnieje tylko w kompozycji
Tu jest sedno, które czyni Cordyceps czymś więcej niż listą podatnych repozytoriów.
Novee opisuje to wprost: ta podatność w łańcuchu dostaw leży w fundamentalnej, otwartoźródłowej instalacji wodno-kanalizacyjnej, na której działa cała branża — i jest rodzajem problemu, który ukrywa się przed skanerami, bo technicznie każdy pojedynczy element działa zgodnie z projektem. Workflow robi to, co mu kazano. Podatność istnieje wyłącznie w kompozycji — niezaufane dane przekraczające granicę zaufania, której nikt nie zaudytował.
Przeczytaj to zdanie jeszcze raz, bo to jest dokładnie ta sama klasa, którą opisywaliśmy przy Agentjacking jako Authorized Intent Chain — gdzie każdy krok jest technicznie autoryzowany, a atak powstaje z ich złożenia. Najgroźniejsze znaleziska Novee to wieloetapowe łańcuchy: niezaufany pull request uruchamia workflow o niskich uprawnieniach, którego wyjście wpływa do workflow o wysokich uprawnieniach, którego token uwierzytelnia się do Google Cloud z rolą właściciela. Żaden pojedynczy krok nie wygląda groźnie. Podatność istnieje tylko w całości łańcucha.
To jest powód, dla którego tradycyjne narzędzia tego nie łapią. Skaner statyczny czyta poprawny YAML i idzie dalej. Atakujący widzi czterokrokową ścieżkę do trwałych poświadczeń chmury. Standardowe narzędzia sprawdzają pojedyncze pliki pod kątem znanych wzorców, ale ryzyko Cordyceps istnieje wyłącznie w tym, jak wiele workflow wchodzi ze sobą w interakcję. Wykrycie tej klasy wymaga symulacji zachowania atakującego od końca do końca — czyli dokładnie tego, co opisywaliśmy jako przewagę AI po stronie ofensywnej, zdolności rozumowania o całym systemie naraz, nie o pojedynczym pliku.
Konkretne przykłady — i dlaczego są przerażające
Novee nie poprzestało na teorii. Pokazało konkretne, działające łańcuchy na infrastrukturze gigantów, i warto je wymienić, bo pokazują skalę.
Na Azure Sentinel Microsoftu komentarz pod pull requestem mógł uruchomić anonimowy kod atakującego na CI Microsoftu i ukraść niewygasający klucz aplikacji GitHub — dający trwały dostęp zapisu do treści detekcji bezpieczeństwa dostarczanych bezpośrednio do środowisk klientów. Zatrzymajmy się tu: to jest platforma bezpieczeństwa, której treść detekcji trafia do klientów. Przejęcie jej oznacza możliwość manipulowania regułami, na których polegają obrońcy — ten sam wzorzec narzędzia bezpieczeństwa jako wektora, który opisywaliśmy przy Apex One i FortiSandbox, tylko na poziomie pipeline'u.
Na AI Agent Development Kit Google'a pojedynczy pull request mógł wykonać kod atakującego na CI Google'a i uzyskać uwierzytelnioną kontrolę nad powiązanym projektem Google Cloud z rolą właściciela — najwyższą możliwą. W Apache Doris dwa ataki typu zero-click sprawiały, że pojedynczy komentarz pod dowolnym PR uruchamiał kod atakującego i wyprowadzał zaszyte poświadczenia CI. Na Workers SDK Cloudflare odpowiednio spreparowana nazwa gałęzi wyzwalała wykonanie dowolnych poleceń na runnerach CI. A na Blacku — formaterze kodu Pythona z 130 milionami instalacji miesięcznie — dowolny pull request mógł ukraść token bota projektu, umożliwiając fałszowanie zatwierdzeń PR i ścieżkę do zatruwania oficjalnych obrazów Docker.
Ten ostatni przykład jest szczególnie pouczający, bo pokazuje pełny zasięg rażenia. Black jest zależnością milionów projektów. Przejęcie jego tokena bota to nie jeden zhakowany projekt — to potencjalne zatrucie obrazów, które pobierają miliony. To jest dokładnie ta logika „skarbca" i mnożnika zasięgu, którą opisywaliśmy przy Miasmie i npm: jeden skompromitowany element w łańcuchu dostaw promieniuje na wszystkich, którzy z niego korzystają.
Sednem: AI rozsiewa ten wzorzec wykładniczo
Tu jest element, który czyni Cordyceps tematem nie o przeszłości, ale o przyszłości — i który spina go z najważniejszym wątkiem, jaki prowadzimy.
Novee wskazuje wprost: te luki rosną szybko, bo agenty AI generują pliki konfiguracyjne CI/CD w tempie wykładniczym, a robiąc to, uporczywie powielają te same niebezpieczne wzorce strukturalne — multiplikując podatność w milionach nietestowanych repozytoriów. Natura agentowego kodowania oznacza, że te podatności CI/CD są reprodukowane uporczywie, na skalę, „infekując" repozytoria w tempie wykładniczym.
To jest dosłownie ta sama teza, którą NCSC postawił dwa dni temu i którą Five Eyes potwierdził: AI pisząca kod nie tylko przyspiesza, ale powiela istniejące niebezpieczne wzorce. NCSC mówił o tym abstrakcyjnie — „wskaźnik defektów na linię kodu pozostaje stały, ale kodu jest więcej". Cordyceps jest konkretnym, zmierzonym dowodem tego mechanizmu. Agent AI poproszony o wygenerowanie workflow GitHub Actions reprodukuje ten sam niebezpieczny wzorzec pull_request_target, który widział w danych treningowych — i robi to za każdym razem, w każdym repozytorium, które go o to poprosi. Metafora grzyba Cordyceps okazuje się podwójnie trafna: to jest model infekcji, w którym małe, powtarzane błędy stają się wykładniczym ryzykiem, bo propagują się przez automatyzację.
To jest najważniejsza zmiana, jaką ten temat wnosi do obrazu. Dotąd „AI powiela błędy" było ostrzeżeniem. Cordyceps pokazuje je jako zmierzone zjawisko: 300+ potwierdzonych łańcuchów w 30 000 repozytoriów, z prognozą Novee, że potencjalnie dotknięte są miliony — bo wzorzec jest reprodukowalny, a agenty go reprodukują.
„Workflow code is code"
Jest jedno zdanie z researchu Novee, które jest najlepszym jednolinijkowym ujęciem przyczyny — i które warto zapamiętać: kod workflow to kod. Błąd w tym kodzie to podatność.
Sedno problemu leży w traktowaniu workflow jako „konfiguracji", a nie jako kodu. Pliki GitHub Actions uruchamiają polecenia powłoki, wykonują skrypty, przechowują tokeny i publikują wydania — a mimo to powszechnie unikają tej samej kontroli bezpieczeństwa, którą stosuje się do kodu aplikacji. To jest luka percepcyjna, nie tylko techniczna. Zespoły, które rygorystycznie audytują kod aplikacji, traktują plik .yml jako nudny szczegół infrastruktury — mimo że ten plik ma dostęp do kluczy podpisujących, poświadczeń chmury i prawa publikacji.
To jest ta sama lekcja, którą opisywaliśmy przy Claude Code GitHub Action i AutoJack: pliki i konfiguracje, które agent albo pipeline czyta, są powierzchnią ataku. Workflow CI/CD nie jest pasywnym rusztowaniem — jest kodem o uprawnieniach krytycznych dla bezpieczeństwa, i zasługuje na taki sam przegląd jak każdy inny kod produkcyjny.
Kontekst i uczciwa ocena ryzyka
Warto zachować proporcje, bo to ważne dla wiarygodności. Wszystkie przetestowane podatności zostały zgłoszone i naprawione — Microsoft i Google potwierdziły wpływ, Cloudflare i Apache wdrożyły utwardzenia i poprawki, Python Software Foundation również. I Meged jest uczciwy co do skali eksploatacji: nie ma dowodów, że jakikolwiek atakujący czy grupa zastosowali ten wzorzec szeroko, na skalę.
To nie znaczy, że ryzyko jest teoretyczne. Znaczy, że zostało wykryte i naprawione u gigantów, zanim ktoś je wykorzystał na masową skalę — ale wzorzec żyje w milionach mniejszych repozytoriów, których nikt nie zaudytował, i jest aktywnie reprodukowany przez AI. To jest okno, w którym obrońcy mają przewagę, jeśli zadziałają teraz — dokładnie ta sama logika, którą Five Eyes opisał jako „miesiące, nie lata".
Jest tu też pozytywny wątek, który warto odnotować. GitHub równolegle wzmienia domyślne ustawienia w tym właśnie obszarze: od 18 czerwca najnowsza wersja actions/checkout domyślnie odmawia pobierania kodu z forkowanych pull requestów w workflow pull_request_target i workflow_run — czyli blokuje dokładnie wzorzec „pwn request", który leży u podstaw wielu łańcuchów Cordyceps. To jest ta sama strukturalna odpowiedź, którą opisywaliśmy przy npm wyłączającym install scripts: producent narzędzia deweloperskiego zmienia domyślne ustawienie z „ufaj automatycznie" na „odmawiaj, dopóki nie pozwolisz".
Co zrobić
Traktuj workflow GitHub Actions jako kod krytyczny dla bezpieczeństwa, nie jako konfigurację. To jest fundamentalna zmiana nastawienia, od której wszystko inne zależy. Plik .yml, który ma dostęp do tokenów i poświadczeń chmury, zasługuje na taki sam przegląd jak kod aplikacji.
Zaudytuj wszystkie workflow pod kątem interpolacji niezaufanego wejścia do poleceń powłoki. Novee wskazuje to jako pierwszy krok: szukaj miejsc, gdzie dane z pull requesta, komentarza albo nazwy gałęzi trafiają do polecenia shell. To jest punkt wejścia większości łańcuchów Cordyceps.
Zwaliduj granice zaufania między poziomami uprawnień workflow. Najgroźniejsze są łańcuchy, w których wyjście workflow o niskich uprawnieniach wpływa do workflow o wysokich. Prześledź, gdzie dane z niezaufanego źródła mogą przepłynąć do workflow z dostępem do poświadczeń — to jest kompozycja, w której żyje podatność.
Zaktualizuj actions/checkout i włącz nowe domyślne zabezpieczenia. Wersja z 18 czerwca blokuje wzorzec pwn request domyślnie. Nie ustawiaj allow-unsafe-pr-checkout, chyba że masz konkretny, przemyślany powód — a wtedy zabezpiecz ten workflow osobno.
Egzekwuj zasadę najmniejszych uprawnień dla tokenów workflow. To jest ta sama lekcja, co przy Claude Code i Agentjacking: jedyną twardą granicą jest to, czego workflow nie może zrobić, bo nie ma uprawnień. Token z rolą właściciela GCP w workflow wyzwalanym przez niezaufany PR to katastrofa czekająca na wyzwolenie.
Jeśli używasz AI do generowania konfiguracji CI/CD — przeglądaj wygenerowane workflow ze szczególną uwagą. To jest konkretne zastosowanie ostrzeżenia NCSC: agent reprodukuje wzorce z danych treningowych, w tym te niebezpieczne. Wygenerowany przez AI plik .yml jest dokładnie tym rodzajem kodu, którego nie wolno akceptować bez zrozumienia.
Źródła
Novee Security — oryginalny research z pełną analizą łańcuchów, przykładami i metodologią skanowania: https://novee.security/blog/cordyceps/
The Hacker News — omówienie z konkretnymi przykładami Microsoft, Google, Apache i cytatami Megeda: https://thehackernews.com/2026/06/cordyceps-cicd-flaws-expose-300-github.html
Dark Reading — analiza mechanizmu pull requestów i potwierdzenie braku masowej eksploatacji: https://www.darkreading.com/application-security/cordyceps-malicious-pull-requests-developer-workflows
SecurityWeek — szczegóły skutków downstream (npm, PyPI, Crates.io, Docker) i kontekst agentic coding: https://www.securityweek.com/exploitable-ci-cd-vulnerabilities-expose-millions-of-repositories-to-hijacking/
Hackread — analiza łańcucha eskalacji uprawnień i przykład Cloudflare Wrangler oraz Black: https://hackread.com/cordyceps-ci-cd-flaw-microsoft-google-apache-repos-hijack/
The Hacker News — kontekst poprawki actions/checkout blokującej pwn requests od 18 czerwca: https://thehackernews.com/2026/06/github-updates-actionscheckout-to-block.html
Nie nowy atak, tylko naprawiony błąd. Co łatka Gemini CLI mówi o tym, że tryb –yolo w potoku CI/CD to nie jest dobry pomysł