Jeśli używasz Claude Code GitHub Action — zaktualizuj do wersji 1.0.94 lub nowszej. Następnie zaudytuj każdy workflow, który pozwala uruchomić Claude'a użytkownikom bez uprawnień zapisu albo botom: jeśli przyjmuje niezaufane dane wejściowe, nie podawaj mu żadnych sekretów poza kluczem API Anthropic i GITHUB_TOKEN, i usuń narzędzia oraz uprawnienia, które mogą posłużyć do eksfiltracji. Sprawdź szczególnie, czy nie skopiowałeś przykładowego workflow z ustawieniem allowed_non_write_users: "*" — Anthropic sam oznacza je w dokumentacji jako ryzykowne.
RyotaK z GMO Flatt Security znalazł w Claude Code GitHub Action błąd, który pozwalał przejąć podatne publiczne repozytorium za pomocą jednej rzeczy: otwartego zgłoszenia (issue). Anthropic ocenił problem na 7.8 w skali CVSS v4.0, naprawił rdzeń w cztery dni od zgłoszenia w styczniu, dosypał kolejnych zabezpieczeń wiosną i wypłacił bug bounty. Poprawki są w claude-code-action 1.0.94.
Ale liczba 7.8 i słowo „naprawione" nie oddają tego, co czyni tę historię ważną. Bo repozytorium samej akcji Anthropic używało tego samego workflow co wszyscy inni — więc działający atak mógł wstrzyknąć złośliwy kod do samej akcji i propagować się w dół, na każdy projekt, który tę akcję pobiera.
To nie jest podatność w jednym repozytorium. To jest podatność, która przez chwilę mogła zatruć narzędzie używane przez tysiące repozytoriów naraz.
Jak działa łańcuch
Claude Code GitHub Action wstawia Claude'a do potoku CI/CD — triażuje zgłoszenia, nakłada etykiety, recenzuje pull requesty, wykonuje polecenia. Domyślnie workflow dostaje dostęp do odczytu i zapisu kodu repozytorium, zgłoszeń, pull requestów, dyskusji i plików workflow. Ponieważ te uprawnienia są szerokie, akcja ma być wybredna co do tego, kto może ją uruchomić — tylko użytkownicy z prawem zapisu.
I tu była dziura. Sprawdzenie uprawnień przepuszczało każdego aktora, którego nazwa kończyła się na [bot] — w założeniu, że aplikacje GitHub to zaufane rzeczy, które instalują administratorzy. Problem: każdy może zarejestrować aplikację GitHub, zainstalować ją na własnym repozytorium i użyć jej tokenu, żeby otworzyć zgłoszenie lub pull request na dowolnym publicznym repozytorium. Akcja widziała „bota" i przepuszczała treść atakującego. Tryb tagowania miał dodatkowe sprawdzenie potwierdzające, że aktor jest prawdziwym człowiekiem; tryb agentowy nie miał — i to on był otwarty.
Dalej wchodzi indirect prompt injection — technika, którą opisywaliśmy przy ChatGPhish i Comment and Control — wstawienie instrukcji do treści, którą AI czyta, tak żeby model wykonał je zamiast swojego zadania. RyotaK napisał zgłoszenie, którego treść wyglądała jak komunikat błędu, i dopracował prompt tak, by Claude „naprawił" sytuację, wykonując polecenia ukryte w środku. Cel: /proc/self/environ — plik Linuksa, który przechowuje zmienne środowiskowe procesu, łącznie z sekretami. Claude Code blokuje naiwne odczyty tego pliku, ale RyotaK obszedł zabezpieczenie i skłonił Claude'a, by zapisał wartości z powrotem do zgłoszenia, gdzie atakujący mógł je odczytać.
Prawdziwą nagrodą w tych zmiennych jest para poświadczeń, której GitHub Actions używa do żądania tokenu OIDC — podpisanego tokenu, który dowodzi „jestem tym workflow działającym w tym repozytorium". Claude Code wymienia ten token w backendzie Anthropic na token instalacyjny aplikacji GitHub z prawem zapisu. Ukradnij poświadczenia, powtórz wymianę, i masz prawo zapisu do kodu, zgłoszeń i workflow celu.
Sednem jest self-poisoning
Tu jest moment, który czyni tę podatność czymś więcej niż przejęciem pojedynczego repozytorium.
Skieruj atak na repozytorium samej claude-code-action — a mogłeś zatruć akcję, którą pobierają projekty w dół łańcucha. Akcja Anthropic używała tego samego podatnego workflow, który udostępniała wszystkim innym. Atakujący, który przejąłby prawo zapisu do tego repozytorium, mógłby wstrzyknąć złośliwy kod do samej akcji — a wtedy każdy projekt, który ją pobiera i uruchamia, dostałby ładunek jako legalną aktualizację zaufanego narzędzia.
To jest dokładnie wzorzec, który opisywaliśmy przez cały tydzień: zaufany kanał jako mnożnik zasięgu. FortiClient EMS, Apex One, KS-SOMED — system zarządzania albo aktualizacji jako droga do wszystkich naraz. Tutaj kanałem jest akcja CI/CD, a mnożnikiem self-propagation: akcja, która zatruwa samą siebie, dystrybuuje się dalej własnym mechanizmem dystrybucji. To jest ta sama logika, co self-replikacja Glassworm i Miasma republikująca pakiety przez OIDC.
To nie jest teoria — łańcuch już raz zadziałał
RyotaK udowodnił atak na samą akcję Anthropic tylko we własnych repozytoriach testowych i jest ostrożny, żeby oddzielić to od wariantów, które faktycznie wykorzystano. Bo ten sam schemat — triażer zgłoszeń oparty na AI, szerokie uprawnienia, prompt injection — już raz spowodował prawdziwe trafienie w łańcuch dostaw.
W lutym prompt-injection w tytule zgłoszenia przeciwko workflow triażowemu Cline pozwolił ukraść token publikacji npm i wypchnąć nieautoryzowaną wersję cline@2.3.0. Tamta wersja tylko wymuszała instalację osobnego, niezłośliwego agenta AI i została wycofana po około ośmiu godzinach — ale ten sam łańcuch mógł równie łatwo dostarczyć prawdziwe malware wszystkim, którzy zaktualizowali.
Potem, pod koniec lutego, autonomiczny bot „HackerBot-Claw" sondował błędne konfiguracje GitHub Actions u Microsoftu, Datadoga, projektów CNCF i innych. Co ciekawe — gdy spróbował prompt-injection przeciwko recenzentowi opartemu na Claude przez zatruty plik konfiguracyjny, Claude to wychwycił i odmówił. Ten szczegół jest wart odnotowania: obrona czasem działa, ale poleganie na tym, że model „złapie" wstrzyknięcie, nie jest kontrolą bezpieczeństwa — jest nadzieją.
Drobny szczegół, który jest większym problemem
RyotaK wskazał też łagodniejszą drogę, która całkowicie pomijała sztuczkę z botem. Przykładowy workflow triażu zgłoszeń od Anthropic był dostarczany z ustawieniem allowed_non_write_users: "*", które pozwala każdemu go uruchomić — ustawienie, które dokumentacja Anthropic sama oznacza jako ryzykowne. Gorzej: Claude publikował podsumowania zadań w publicznie widocznym panelu podsumowania uruchomienia workflow — gotowy sposób na wyciek danych na zewnątrz. Wiele repozytoriów skopiowało ten przykład i odziedziczyło dziurę.
To jest problem, który wykracza poza jeden błąd w sprawdzaniu uprawnień. Kiedy dostawca publikuje przykładową konfigurację z ryzykownym ustawieniem, to ustawienie rozchodzi się po wszystkich projektach, które kopiują przykład — niezależnie od tego, czy główny błąd zostanie załatany. Bezpieczne domyślne ustawienia w przykładach są częścią powierzchni ataku.
Liczba, która jest najważniejsza
Jest jedno zdanie w raporcie, które warto zapamiętać bardziej niż samą podatność. RyotaK mówi, że zgłosił już około 50 osobnych sposobów na obejście systemu uprawnień Claude Code i wykonanie poleceń — w ramach ciągłej serii błędów prompt injection w agentach AI do kodowania.
Pięćdziesiąt obejść jednego systemu uprawnień, zgłoszonych przez jednego badacza. To nie jest historia o jednym błędzie, który załatano w cztery dni. To jest historia o tym, że prompt injection wciąż nie jest rozwiązany — a agent z prawdziwymi narzędziami i prawdziwymi tokenami może zostać popchnięty tak daleko, jak pozwalają jego uprawnienia.
To jest ta sama lekcja, którą zapisaliśmy w analizie prompt leaking: ograniczenia na poziomie instrukcji językowej są miękkie. Model można przekonać, żeby zignorował zdanie. Jedyną twardą granicą jest to, czego agent fizycznie nie może zrobić — uprawnienia, tokeny, narzędzia, których po prostu nie ma. Dlatego właściwa obrona to nie „lepszy prompt systemowy", ale odebranie agentowi dostępu do sekretów i narzędzi eksfiltracji, zanim ktoś go o nie poprosi.
Co warto docenić
Mimo wszystko warto odnotować, co poszło dobrze. RyotaK zgłosił błąd w styczniu, Anthropic naprawił rdzeń w cztery dni, dosypał zabezpieczeń przez wiosnę, wypłacił bug bounty i przypisał ocenę CVSS. To jest wzorcowy responsible disclosure — i kontrast wobec sporu Microsoftu z Chaotic Eclipse czy odmowy serwisowania przy wycieku NTLM, które opisywaliśmy w tym tygodniu. Cztery dni do naprawy rdzenia krytycznego błędu w narzędziu CI/CD to dobra reakcja.
Problemem nie jest reakcja Anthropic. Problemem jest klasa: agenty AI z szerokimi uprawnieniami, czytające niezaufane dane wejściowe, są strukturalnie podatne na prompt injection — i będą takie, dopóki prompt injection pozostaje nierozwiązany. Łatanie pojedynczych obejść jest konieczne, ale RyotaK ma ich jeszcze czterdzieści kilka.
Co zrobić
Zaktualizuj claude-code-action do wersji 1.0.94 lub nowszej.
Zaudytuj każdy workflow, który pozwala uruchomić Claude'a użytkownikom bez prawa zapisu lub botom. Jeśli przyjmuje niezaufane dane — nie podawaj mu sekretów poza kluczem API Anthropic i GITHUB_TOKEN, usuń narzędzia i uprawnienia umożliwiające eksfiltrację.
Sprawdź, czy nie odziedziczyłeś allowed_non_write_users: "*" z przykładowego workflow. Jeśli tak — ogranicz, kto może uruchomić akcję.
Wyłącz publikowanie podsumowań Claude'a do publicznie widocznego panelu uruchomienia, jeśli workflow przetwarza cokolwiek niezaufanego — to jest gotowy kanał wycieku.
Traktuj każdy plik, który agent AI czyta — zgłoszenia, pull requesty, pliki konfiguracyjne, CLAUDE.md — jako potencjalnie niezaufane wejście. To jest ten sam wniosek, co przy TrapDoor: pliki, które agent czyta, są powierzchnią ataku.
Źródła
GMO Flatt Security / RyotaK — pełny research techniczny z łańcuchem ataku: https://flatt.tech/research/posts/poisoning-claude-code-one-github-issue-to-break-the-supply-chain/
The Hacker News — omówienie z kontekstem ataków Cline i HackerBot-Claw: https://thehackernews.com/2026/06/claude-code-github-action-flaw-let-one.html
Anthropic — commit z poprawką rdzenia podatności: https://github.com/anthropics/claude-code-action/commit/1bbc9e7ff7d48e1299f7fa9698273d248e0cafea
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ł