Nowo wydane przez GitHub Agentic Workflows mogą zostać oszukane, aby publikowały pliki z prywatnych repozytoriów – wykazali to badacze z Noma Labs, pokazując, że pojedynczy publiczny komentarz w zgłoszeniu (issue) może zmienić wewnętrznego asystenta AI w kanał wycieku danych.

Luka ta jest istotna, ponieważ omija wbudowane mechanizmy bezpieczeństwa GitHub bez użycia specjalnego kodu exploita; atakujący musi jedynie przygotować pozornie niewinną treść zgłoszenia, którą agent AI przeczyta i na której podejmie działania.

Jak działa ta podatność

Agentic Workflows pozwalają agentowi AI reagować na zdarzenia w GitHub – takie jak nowe zgłoszenia (issues) – poprzez wykonywanie poleceń zdefiniowanych w pliku workflow. Noma Labs odkryło, że agent nie rozróżnia uprawnionych instrukcji workflow od tekstu zawartego w komentarzu przesłanym przez użytkownika. Poprzez opublikowanie publicznego zgłoszenia, które naśladuje prośbę menedżera i dodanie ukrytej dyrektywy, atakujący może nakierować agenta na:

  1. Otwarcie zgłoszenia (widocznego publicznie).
  2. Dołączenie linii, która wygląda zwyczajnie, ale zawiera ukryte polecenie.
  3. Wywołanie u AI działania polegającego na pobraniu plików z prywatnego repozytorium, do którego workflow ma uprawnienia w zakresie odczytu.
  4. Skłonienie agenta do opublikowania pobranej zawartości jako odpowiedzi w tym samym zgłoszeniu.

Badacze odkryli, że wstawienie pojedynczego słowa „Additionally,” przed ukrytą komendą wystarczyło, aby ominąć zabezpieczenia GitHub. Nie są wymagane żadne dodatkowe uprawnienia, tokeny ani niestandardowy kod – wystarczy odpowiednie sformułowanie.

Dlaczego to coś więcej niż błąd

Problem ma charakter strukturalny. Agent AI traktuje każdy tekst otrzymany w ramach zdarzenia repozytorium jako godny zaufania, co w praktyce czyni treści generowane przez użytkowników wektorem wejściowym, podobnym do ataku SQL injection w aplikacjach webowych. Jeśli workflow nadaje agentowi uprawnienia do odczytu prywatnych repozytoriów oraz możliwość publicznego komentowania, połączenie to tworzy bezpośrednią ścieżkę do eksfiltracji danych.

Co mówi GitHub

GitHub został powiadomiony o tej luce.

Kroki mitygacyjne dla zespołów

  • Ogranicz uprawnienia agenta: Nadawaj uprawnienia do odczytu/zapisu w prywatnych repozytoriach tylko wtedy, gdy jest to absolutnie konieczne.
  • Zablokuj publiczne publikowanie: Skonfiguruj workflow tak, aby agenci nie mogli publikować komentarzy ani innych artefaktów w publicznych zgłoszeniach.
  • Traktuj wszystkie dane wejściowe z zewnątrz jako niepewne: Dodaj warstwy walidacji, które oczyszczają lub ignorują tekst generowany przez użytkowników, zanim dotrze on do AI.
  • Audytuj wyzwalacze workflow: Przejrzyj, które zdarzenia (issues, pull requests itp.) uruchamiają agentów i zweryfikuj, czy powiązane uprawnienia odpowiadają zamierzonemu przypadkowi użycia.

Wniosek: Asystent AI, który może czytać prywatny kod i publikować treści publicznie, jest tak bezpieczny, jak granice, które wokół niego wyznaczysz. Bez ścisłych limitów uprawnień i oczyszczania danych wejściowych, pojedynczy publiczny komentarz może zmienić funkcję zwiększającą produktywność w wektor wycieku danych.