Aonan Guan otworzył zgłoszenie na GitHubie. W tytule wpisał złośliwą instrukcję. Asystent AI przeczytał ją, wykonał polecenia i wkleił skradzione klucze API z powrotem do komentarza pod tym samym zgłoszeniem.
Żadnego zewnętrznego serwera. Żadnego złośliwego oprogramowania. Żadnej interakcji ofiary. Cały atak zamknął się wewnątrz GitHuba — od złośliwego tytułu do wykradzionego klucza — z asystentem AI jako nieświadomym wykonawcą.
Badacze z Johns Hopkins University opublikowali wyniki pod nazwą Comment and Control — celową grę słów z Command and Control, klasyczną infrastrukturą sterowania złośliwym oprogramowaniem. Tym razem infrastruktura sterowania to komentarze na GitHubie, a agent wykonujący polecenia to Claude, Gemini lub Copilot.
Dlaczego to jest inne niż poprzednie wstrzyknięcia
Pisaliśmy o GrafanaGhost i stored indirect prompt injection — złośliwej treści przechowywanej w danych, którą agent przetwarza gdy zapytany o konkretny zasób. Tamten atak był reaktywny: agent musiał zostać poproszony o przetworzenie zainfekowanego zasobu, żeby złośliwa instrukcja zadziałała.
Comment and Control jest proaktywny. Przepływy pracy GitHub Actions uruchamiają się automatycznie przy zdarzeniach pull_request, issues i issue_comment — samo otwarcie zgłoszenia lub złożenie propozycji zmian aktywuje agenta bez żadnej decyzji ofiary. Atakujący pisze komentarz. Agent czyta go jako część kontekstu zadania, wykonuje zawarte instrukcje i odsyła wyniki przez ten sam kanał.
Nie ma momentu w którym człowiek mógłby zatrzymać atak — bo nie ma momentu w którym człowiek jest pytany o zdanie.
Trzy agenty, jeden wzorzec
Guan przetestował trzy powszechnie używane agenty AI zintegrowane z GitHub Actions.
Claude Code Security Review — narzędzie Anthropic do automatycznej analizy bezpieczeństwa kodu w zgłoszeniach zmian. Tytuł zgłoszenia jest bezpośrednio interpolowany do monitu systemowego bez żadnej sanityzacji. Claude CLI jest wywoływany bez ograniczeń narzędziowych — podproces dziedziczy wszystkie zmienne środowiskowe, w tym ANTHROPIC_API_KEY i GITHUB_TOKEN. Guan otworzył zgłoszenie ze złośliwym tytułem instruującym Claude do wykonania env, a agent zwrócił pełny zrzut zmiennych środowiskowych jako "ustalenia bezpieczeństwa" w komentarzu. Anthropic ocenił podatność jako CVSS 9.4 — krytyczną. Wypłacił 100 dolarów nagrody.
Gemini CLI Action — odpowiednik Google. Podobny mechanizm: złośliwa instrukcja w sekcji zgłoszenia, Gemini opublikował GEMINI_API_KEY jako komentarz. Google wypłacił 1337 dolarów.
GitHub Copilot Agent — najtrudniejszy cel i najbardziej interesujący technicznie. GitHub zbudował trzy warstwy ochrony w czasie wykonania: filtrowanie zmiennych środowiskowych, skanowanie sekretów i zaporę sieciową. Guan ominął wszystkie trzy przez ukrycie ładunku w komentarzu HTML — niewidocznym w wyrenderowanym widoku Markdown, ale w pełni przetwarzanym przez agenta. Ofiara widzi niewinne zgłoszenie i przypisuje je do Copilota. Agent widzi ukrytą instrukcję i wykonuje ją. GitHub wypłacił 500 dolarów i po cichu naprawił błąd.
Żaden z trzech vendorów nie opublikował publicznego ostrzeżenia. Żaden nie przypisał podatności identyfikatora CVE. Skanery bezpieczeństwa pokazują zielone światło dla błędu ocenionego przez Anthropic jako krytyczny.
Architektura problemu
Guan wyjaśnia strukturalną przyczynę jednym zdaniem: "Wszystkie trzy podatności mają ten sam błąd architektoniczny — niezaufane dane z GitHuba trafiają do agenta AI, który trzyma produkcyjne sekrety i nieograniczony dostęp do narzędzi w tym samym środowisku uruchomieniowym."
To jest dokładnie ta sama klasa problemu którą opisywaliśmy przy raporcie OX Security o architektonicznym błędzie w STDIO w MCP — niezaufane wejście trafia do środowiska wykonawczego, które ma dostęp do produkcyjnych sekretów, bez mechanizmu separującego te dwa światy.
Tam problem siedział w warstwie protokołu. Tu siedzi w warstwie integracji: agent dostaje dostęp do sekretów produkcyjnych bo potrzebuje ich do pracy, i jednocześnie przetwarza niezaufane dane z zewnątrz bo to jest jego zadanie. Nikt nie zadał pytania co się stanie gdy te dwa konteksty się zetkną.
Analityk bezpieczeństwa Baer ujmuje to wprost: "Surowe zero-days nie są tym jak większość systemów zostaje skompromitowana. Chodzi o złożoność. Klej między systemami, tokeny w CI, agenty z nadmiernymi uprawnieniami. Gdy podłączysz potężny model do środowiska z szerokimi uprawnieniami, atakujący ma już większość roboty za sobą."
Zasięg wykracza poza GitHub
Guan w swoim opisie zatrzymuje się przy ważnym wniosku: wzorzec nie ogranicza się do GitHub Actions. "Dotyczy każdego agenta, który przetwarza niezaufane wejście mając jednocześnie dostęp do narzędzi i sekretów — boty Slack, agenty Jira, agenty poczty elektronicznej, automatyzacja wdrożeń. Powierzchnia wstrzyknięcia się zmienia, wzorzec pozostaje ten sam."
Google DeepMind opisywał sześć klas pułapek webowych dla agentów — Comment and Control dodaje siódmą klasę, ulokowaną nie w treści stron które agent odwiedza, ale w treści platformy współpracy która jest jego środowiskiem pracy. Nie sieć zaatakowała agenta. Repozutorium kodu zaatakowało agenta.
To ma bezpośrednie konsekwencje dla środowisk, które wdrożyły asystentów AI w narzędziach takich jak Jira, Confluence, Notion czy Slack. Jeśli agent ma dostęp do tych systemów i jednocześnie przetwarza treści tworzone przez zewnętrznych użytkowników — ma tę samą architektoniczną podatność, niezależnie od tego czy ktoś ją już odkrył i zgłosił.
Copilot jako osobna lekcja
Przypadek GitHub Copilot Agent zasługuje na osobne zdanie — nie dlatego że był najtrudniejszy do zaatakowania, ale dlatego że był najtrudniejszy i i tak padł.
Trzy warstwy ochrony w czasie wykonania to poważna inwestycja w bezpieczeństwo. Filtrowanie zmiennych środowiskowych, skanowanie sekretów, zapora sieciowa — każda z tych warstw jest odpowiedzią na konkretną klasę ataków. Razem tworzyły solidną obronę w głąb.
Guan ominął wszystkie trzy przez HTML comment — trzy znaki <!-- na początku ładunku, które są standardowym komentarzem w Markdown i w standardowym widoku GitHub są zupełnie niewidoczne. Agent przetwarza surowy tekst, nie wyrenderowany widok. Wie o komentarzu HTML. Człowiek go nie widzi.
To jest klasyczny przykład różnicy między tym co widzi człowiek a tym co przetwarza maszyna — tej samej różnicy którą eksploituje tool poisoning w ekosystemie MCP, gdzie opisy narzędzi widoczne dla agenta różnią się od tego co widzi deweloper konfigurujący integrację.
Nagrody i co mówią o priorytetach
Zestawienie wypłaconych nagród jest warte chwili refleksji.
Anthropic: CVSS 9.4, 100 dolarów. Google: porównywalny błąd, 1337 dolarów. GitHub: 500 dolarów.
Guan wprost komentuje dysproporcję przy Anthropic: program HackerOne Anthropic wycenia błędy w narzędziach agentowych osobno niż podatności bezpieczeństwa modeli — co przekłada się na znacznie niższe nagrody dla tej klasy błędów. To jest decyzja organizacyjna o tym co jest "prawdziwym" problemem bezpieczeństwa, a co jest kwestią narzędziową.
Problem polega na tym, że z perspektywy atakującego który wyciąga klucz produkcyjny przez tytuł zgłoszenia na GitHubie — ta taksonomia nie ma żadnego znaczenia.
Co zrobić teraz
Dla zespołów używających AI agentów w GitHub Actions: sprawdzić konfigurację wyzwalaczy. Przepływy używające pull_request_target zamiast pull_request wstrzykują sekrety do środowiska uruchomieniowego — dla zewnętrznych propozycji zmian to jest bezpośredni wektor ataku.
Konfiguracja klucza permissions ograniczająca zakres GITHUB_TOKEN, reguły ochrony środowisk wymagające zatwierdzenia przed wstrzyknięciem sekretów i bramy dla pierwszych kontrybutorów blokują tę klasę ataków w większości scenariuszy.
Szerszy wniosek: każdy agent AI zintegrowany z platformą przyjmującą treści od zewnętrznych użytkowników powinien być traktowany jako potencjalnie podatny na Comment and Control — niezależnie od platformy. Nie tylko GitHub. Jira, Confluence, Slack, e-mail. Wszędzie gdzie agent przetwarza niezaufane wejście i ma jednocześnie dostęp do sekretów.
Podsumowanie
Comment and Control nie jest kolejną podatnością z listy CVE. Jest opisem klasy architektonicznych błędów, które będą pojawiać się w każdym narzędziu integrującym agenta AI z platformą współpracy.
Dr Andrew Bolster z Black Duck mówi wprost: "Połączenia między wejściem modelu językowego, kontekstem i narzędziami wymagają takiego samego sanityzowania i zabezpieczenia jak poprzednie generacje aplikacji chroniły się przed SQL injection i cross-site scripting."
SQL injection przez dekady był traktowany jako "znany problem" przez programistów którzy wiedzieli że trzeba sanityzować dane, ale nie zawsze to robili. Historia pokazała jak to się skończyło. Comment and Control stawia to samo pytanie w nowym kontekście.
Źródła
VentureBeat — szczegółowa analiza ujawnień i porównanie kart systemowych vendorów: https://venturebeat.com/security/ai-agent-runtime-security-system-card-audit-comment-and-control-2026
SecurityWeek — opis techniczny ataku na wszystkich trzech agentów: https://www.securityweek.com/claude-code-gemini-cli-github-copilot-agents-vulnerable-to-prompt-injection-via-comments/
Cybersecurity News — mechanizm Claude Code Security Review i przepływ ataku: https://cybersecuritynews.com/prompt-injection-via-github-comments/
Cybernews — komentarze badaczy i brak publicznych ostrzeżeń vendorów: https://cybernews.com/security/ai-agents-github-prompt-injection-pattern/
Techzine — szczegóły obejścia trzech warstw ochrony Copilota: https://www.techzine.eu/news/security/140524/ai-agents-on-github-leak-api-keys-via-prompt-injection/
