GitHub Issues jako wektor ataku na Copilot: „RoguePilot” i scenariusz przejęcia repozytorium w Codespaces - Security Bez Tabu

GitHub Issues jako wektor ataku na Copilot: „RoguePilot” i scenariusz przejęcia repozytorium w Codespaces

Wprowadzenie do problemu / definicja luki

W lutym 2026 r. opisano podatność, w której zwykły opis zgłoszenia (GitHub Issue) może stać się nośnikiem złośliwych instrukcji dla GitHub Copilot uruchomionego wewnątrz GitHub Codespaces. Kluczowy problem nie polega na „błędzie w LLM”, tylko na zbyt głębokiej automatyzacji: podczas tworzenia Codespace z kontekstu Issue treść zgłoszenia jest automatycznie wykorzystywana jako prompt dla asystenta, co otwiera drogę do passive prompt injection.

To typ zagrożenia klasyfikowany szerzej jako prompt injection (LLM01 w OWASP Top 10 dla aplikacji LLM), gdzie atakujący manipuluje zachowaniem modelu przez odpowiednio spreparowane dane wejściowe.

W skrócie

  • Atak nazwany RoguePilot pokazuje łańcuch, w którym Issue → automatyczny prompt w Codespaces → działania Copilota → eksfiltracja tokenu.
  • W wariancie opisanym przez badaczy możliwe było doprowadzenie do wycieku uprzywilejowanego GITHUB_TOKEN z Codespaces, co w konsekwencji umożliwiało przejęcie repozytorium (zależnie od uprawnień tokenu).
  • Wykorzystano m.in. ukryte instrukcje w HTML comments w treści Issue oraz mechanizm automatycznego pobierania JSON schema w VS Code jako kanał eksfiltracji.
  • GitHub wdrożył poprawki po zgłoszeniu (responsible disclosure).

Kontekst / historia / powiązania

RoguePilot wpisuje się w rosnącą klasę zagrożeń, gdzie LLM staje się „pośrednikiem wykonawczym”: nie tylko generuje tekst, ale też steruje narzędziami w środowisku deweloperskim. To zmienia model ryzyka z „halucynacji” na AI-mediated supply chain attack — złośliwe instrukcje mogą pochodzić z treści, które dotąd traktowano jako „bezpieczne metadane projektu” (Issues, komentarze, opisy PR).

OWASP podkreśla, że prompt injection jest ryzykiem numer 1 dla systemów LLM, bo modele nie mają naturalnej granicy między „danymi” a „instrukcją”.

Analiza techniczna / szczegóły luki

1) Punkt wejścia: Issue jako „prompt”

W opisywanym scenariuszu uruchomienie Codespace z poziomu Issue powodowało, że Copilot w środowisku miał zostać automatycznie zapromptowany treścią zgłoszenia. To wystarcza, aby atakujący (np. w repo publicznym lub w repo, gdzie może tworzyć Issues) umieścił w opisie instrukcje dla agenta.

2) Ukrycie instrukcji: HTML comments

Badacze wskazali, że złośliwe polecenia można ukryć w <!-- -->, dzięki czemu człowiek „na oko” widzi zwykłe zgłoszenie, a model nadal przetwarza pełną treść.

3) Pozyskanie sekretu: GITHUB_TOKEN z Codespaces

W Codespaces dostępny jest GITHUB_TOKEN jako domyślna zmienna środowiskowa; GitHub opisuje go jako podpisany token uwierzytelniający użytkownika w codespace, możliwy do użycia np. do wywołań GitHub API.
W łańcuchu RoguePilot token miał zostać odczytany z pliku wewnątrz środowiska Codespaces (wskazywanego w analizie badaczy) i następnie wyprowadzony na zewnątrz.

4) Ominięcie ograniczeń ścieżki: symlink + PR checkout

W opisie ataku pojawia się wykorzystanie symbolicznego linku w repozytorium oraz nakłonienie Copilota do przełączenia się na przygotowany PR, w którym symlink wskazuje na wrażliwy plik w obszarze współdzielonym Codespaces.

5) Kanał eksfiltracji: automatyczne pobieranie JSON schema

Kluczowa sztuczka: VS Code potrafi automatycznie pobierać schema dla JSON, gdy w pliku występuje pole $schema. Badacze opisują, że ustawienie json.schemaDownload.enable jest w Codespaces włączone domyślnie, więc można je nadużyć jako „legalny” outbound request i dopiąć wykradane dane do URL schemy (np. w query string).
Istnienie przełącznika json.schemaDownload.enable jako opcji, która ma umożliwić wyłączenie pobierania schem, jest udokumentowane w ekosystemie VS Code.

Praktyczne konsekwencje / ryzyko

  1. Przejęcie repozytorium i supply chain
    Jeśli GITHUB_TOKEN ma uprawnienia zapisu, atakujący może wypchnąć zmiany, otworzyć/zmodyfikować PR-y, wstrzyknąć backdoora, podmienić workflow itp. To klasyczny scenariusz supply chain, tylko uruchamiany przez „zainfekowany kontekst” dla agenta AI.
  2. Atak bez „klikania w link” i bez socjotechniki wprost
    W wielu organizacjach tworzenie Codespace do „szybkiego ogarnięcia issue” jest normalnym nawykiem. Wtedy atak jest bliski „zero-interaction”: nie trzeba, by ofiara wkleiła prompt — wystarczy, że otworzy Codespace z Issue.
  3. Trudniejsza detekcja
    Instrukcje ukryte w komentarzach HTML i eksfiltracja przez „normalny” request po schema wyglądają jak działania narzędzia, a nie malware.

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów dev / AppSec

  • Traktuj Issue/PR/README jako dane nieufne dla agentów AI: jeśli narzędzie automatycznie wciąga kontekst, załóż, że będzie on adversarial.
  • Ogranicz tokeny w środowiskach developerskich: skróć TTL, minimalizuj scope, rozważ rozdzielenie tokenów „do odczytu” i „do zapisu” w zależności od tasku. (Ryzyko dotyczy tego, że Codespaces udostępnia GITHUB_TOKEN do działań w repo).
  • Wyłącz lub ogranicz automatyczne pobieranie schem JSON w środowiskach, gdzie ma to sens (np. polityka organizacyjna/konfiguracje VS Code/Dev Container) — to usuwa prosty kanał eksfiltracji oparty o $schema.
  • Wykrywanie ukrytych promptów: automatyczne skanowanie treści Issue/PR pod kątem podejrzanych wzorców (np. długie instrukcje, „system prompt”-like frazy, fragmenty nakazujące pobieranie z URL, polecenia dot. tokenów/sekretów).
  • Blokada/monitoring outbound z Codespaces (jeśli to możliwe w modelu sieciowym): allowlisty domen, detekcja anomalii w żądaniach HTTP GET z parametrami przypominającymi dane.

Dla maintainerów repozytoriów

  • Ogranicz możliwość tworzenia Issues (w publicznych repo rozważ moderację/triage, szablony, wymaganie konta o określonym zaufaniu).
  • Polityka „nie odpalamy Codespace bez weryfikacji treści Issue”: szczególnie dla zgłoszeń od nowych kont.

Dla vendorów / dostawców narzędzi AI

  • Fail-safe defaults: nie wolno pasywnie promptować agenta treścią z repo bez wyraźnego „consent” i warstwy sanitizacji; trzeba też blokować ścieżki eksfiltracji (np. automatyczne fetchowanie zasobów po URL).

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

  • Klasyczny prompt injection zwykle dotyczy czatu/aplikacji, gdzie użytkownik wkleja treść. W RoguePilot mamy passive prompt injection: model „sam” konsumuje treść z Issue przy starcie środowiska.
  • W odróżnieniu od ataków stricte na zależności (typosquatting, dependency confusion), tutaj „wejściem” jest artefakt procesowy SDLC (Issue), a „wykonawcą” — agent AI z uprawnieniami do narzędzi i tokenów.

Podsumowanie / kluczowe wnioski

RoguePilot to mocny przykład, że integracje agentów AI w narzędziach deweloperskich mogą tworzyć nowe łańcuchy ataku: dane, które do tej pory były „tylko tekstem w trackerze”, stają się instrukcją sterującą automatem z dostępem do sekretów i operacji na repo.

Najważniejsze działania obronne to:

  • odcięcie pasywnego zaufania do kontekstu (Issues/PR jako untrusted),
  • minimalizacja i kontrola GITHUB_TOKEN,
  • redukcja automatycznych mechanizmów pobierania zasobów (np. schema),
  • oraz polityki operacyjne „jak bezpiecznie używać agent mode”.

Źródła / bibliografia

  1. Orca Security Research Pod – „RoguePilot: Exploiting GitHub Copilot for a Repository Takeover” (16 lutego 2026). (Orca Security)
  2. SecurityWeek – „GitHub Issues Abused in Copilot Attack Leading to Repository Takeover” (24 lutego 2026). (SecurityWeek)
  3. GitHub Docs – „Default environment variables for your codespace” (opis GITHUB_TOKEN). (GitHub Docs)
  4. OWASP GenAI – LLM01: Prompt Injection (oraz OWASP Top 10 for LLM Applications). (OWASP Gen AI Security Project)
  5. Microsoft VS Code – issue dot. ustawienia json.schemaDownload.enable (wyłączenie pobierania schem). (GitHub)