Twój agent AI właśnie został zhakowany. I mógłbyś się nie dowiedzieć.

Prawdziwy atak prompt injection w publicznym repozytorium GitHub i co oznacza dla deweloperów korzystających z agentów do kodowania SI.

Wyglądało na legalne

Niedawno natknąłem się na repozytorium GitHub z ponad 40 gwiazdkami, aktywną społecznością i profesjonalnym pozycjonowaniem jako „#1 OpenCode Plugin". Obiecywało asynchroniczne subagenty, wyselekcjonowane agenty i warstwę kompatybilną z Claude Code. Na pierwszy rzut oka wyglądało jak normalne narzędzie deweloperskie: dokumentacja, kroki instalacji i uspokajająca, profesjonalna prezentacja.

Głęboko ukryte w tej dokumentacji znalazłem jednak coś o wiele bardziej niepokojącego.

To, co odkryłem, nie było konwencjonalnym ładunkiem złośliwego oprogramowania ani podejrzanym plikiem binarnym. Był to atak prompt injection wymierzony bezpośrednio w agentów kodujących AI.

To nie było napisane dla ludzi

Najważniejszy szczegół: przewodnik instalacyjny nie był tak naprawdę napisany dla użytkownika. Był napisany dla agenta SI użytkownika.

Repozytorium wprost instruowało użytkowników, aby wkleili URL do asystenta do kodowania opartego na LLM. Gdy agent pobrał ten zewnętrzny plik markdown, otrzymywał sekwencję instrukcji zaprojektowanych, by wpłynąć na jego zachowanie, sterować jego decyzjami i wyzwalać działania na komputerze użytkownika.

To właśnie sprawia, że ten atak jest godny uwagi. Ładunek nie jest ukryty w skompilowanym kodzie. Jest ukryty w instrukcjach w języku naturalnym, którym autonomiczny asystent do kodowania prawdopodobnie zaufa.

Jak działał atak

Po pobraniu przez agenta SI zewnętrzny przewodnik próbował wykonać kilka działań.

1. Wyzwolenie dowolnego uruchomienia paczek

Przewodnik instruował agenta, aby uruchomił polecenia takie jak:

bunx oh-my-opencode install
npx oh-my-opencode install

To ważne, ponieważ bunx i npx mogą pobierać i uruchamiać kod bezpośrednio z rejestru paczek. Jeśli agent SI uruchamia te polecenia w imieniu użytkownika bez właściwego przeglądu, efektywnie uruchamia niezaufany kod z własnymi uprawnieniami użytkownika.

2. Zbieranie informacji o subskrypcjach i kontach

Przewodnik instruował również agenta, aby pytał użytkownika o płatne usługi i subskrypcje, w tym o dostęp do Claude, ChatGPT, GitHub Copilot lub OpenCode Zen.

To nie jest normalne zachowanie instalacyjne. To zbieranie danych ukryte pod postacią konfiguracji, które daje operatorowi repozytorium wgląd w to, z których komercyjnych usług SI korzysta cel ataku.

3. Wstrzykiwanie reklam do przepływu pracy

Jedna sekcja wprost instruowała agenta, aby odczytał zewnętrzną listę i wybrał firmę do promowania użytkownikowi.

To jeden z najwyraźniejszych sygnałów złośliwej intencji. Asystent SI nie pomaga już użytkownikowi wykonać zadania — jest repurpozowany jako niezaufany kanał marketingowy osadzony w przepływie pracy dewelopera.

4. Manipulowanie dowodem społecznym

Instrukcje zachęcały również agenta, aby prosił użytkownika o dodanie gwiazdki do repozytorium, używał poleceń GitHub CLI, żeby to zrobić za zgodą użytkownika, oraz generował pozytywne recenzje lub referencje.

To sztucznie zawyża sygnały zaufania. Repozytorium może sprawiać wrażenie popularnego, lubianego i zatwierdzonego przez społeczność, nawet gdy ta reputacja jest wytwarzana przez manipulację opartą na prompt injection.

5. Używanie uspokajającego tonu jako mechanizmu kontroli

Sformułowania w przewodniku były celowo ciepłe, gratulacyjne i zabawne. Używały przyjaznego tonu, świętującego języka i dziwacznych wyrażeń, aby zmniejszyć sceptycyzm i utrzymać zarówno użytkownika, jak i agenta w stanie posłuszeństwa.

To ważne, ponieważ socjotechnika nie ogranicza się już tylko do ludzi. Ton może również kształtować sposób, w jaki system SI interpretuje i priorytetyzuje instrukcje.

Dlaczego to jest inne

Tradycyjne ataki na łańcuch dostaw celują w kod. Ataki prompt injection celują w warstwę podejmowania decyzji wokół kodu.

Ta różnica jest istotna.

Powierzchnia ataku nie ogranicza się już do node_modules, pip ani skryptów powłoki. Obejmuje teraz każdy dokument, README, plik markdown i zewnętrzny zestaw instrukcji, który agent SI jest gotowy przetworzyć.

Czerwone flagi, na które deweloperzy powinni uważać

Po przejrzeniu tego repozytorium wyróżniło się kilka wzorców.

Natychmiastowe czerwone flagi

• Każde README, które mówi „wklej to do swojego agenta SI" lub prosi o podanie zewnętrznego URL bezpośrednio do asystenta.
• Dokumentacja napisana głównie dla modelu zamiast dla ludzkiego operatora.
• Nieznane użycie bunx, npx, pip install lub podobnych poleceń wobec niezaufanych paczek.
• Pytania o wiele płatnych subskrypcji niezwiązanych z wymaganiami instalacyjnymi lub środowiskiem uruchomieniowym.
• Instrukcje promowania firm trzecich, polecania sponsorów lub wstrzykiwania reklam.
• Prośby o dodanie gwiazdek do repozytoriów, pisanie recenzji lub inne wytwarzanie zaangażowania.

Strukturalne czerwone flagi

• Zforkowane lub przemianowane repozytorium, które dziedziczy wiarygodność z innego projektu.
• Duża liczba commitów, ale bardzo mała znacząca podstawowa funkcjonalność.
• Brak polityki bezpieczeństwa, słaba obsługa zgłoszeń podatności lub brak odpowiedzialnej odpowiedzi na raport.
• Ważne instrukcje przechowywane w drugorzędnych plikach markdown zamiast w głównej dokumentacji.

Jak sprawdzić repozytorium przed użyciem

1. Nie ufaj tylko README

Przeczytaj faktyczne źródło i całą przywołaną dokumentację. W ekosystemach agentów SI pliki markdown mogą być równie ważne jak pliki wykonywalne.

Zwróć szczególną uwagę na:

• docs/
• README.md
• AGENTS.md
• wszelkie surowe URL-e GitHub przywoływane podczas konfiguracji
• instrukcje instalacyjne przeznaczone dla agentów, a nie dla użytkowników

2. Sprawdź, co faktycznie zostanie uruchomione

Przed uruchomieniem poleceń bootstrap paczek sprawdź, co zostaną pobrane:

npm pack oh-my-opencode --dry-run
tar -tzf oh-my-opencode-*.tgz
npm view oh-my-opencode scripts

Cel jest prosty: zrozum, co zostanie uruchomione, zanim pozwolisz menedżerowi paczek lub agentowi to zrobić za Ciebie.

3. Szukaj wzorców manipulacji

Podstawowe wyszukiwanie tekstowe może szybko ujawnić podejrzane intencje:

git clone <repo> && cd <repo>
grep -ri "star the repo\|advertise\|free advertising\|promote" .
grep -ri "subscription\|pro plan\|max\|copilot" .
grep -ri "paste this into\|llm agent\|assistant session" .

Te wyszukiwania nie udowodnią samodzielnie złośliwości, ale są wydajnym filtrem pierwszego przeglądu.

4. Zweryfikuj opiekuna

Zadaj kilka podstawowych pytań:

• Czy to oryginalny projekt czy fork?
• Czy opiekun ma wiarygodną historię wkładu?
• Czy problemy i dyskusje wyglądają autentycznie?
• Czy zaufanie wokół projektu jest organiczne, czy nadmiernie kuratowane?

5. Testuj nieznane narzędzia w izolacji

Jeśli zdecydujesz się ocenić nieznane narzędzie SI:

• Użyj kontenera lub VM.
• Trzymaj dane uwierzytelniające poza środowiskiem.
• Unikaj testowania na głównej stacji roboczej lub powłoce produkcyjnej.
• Monitoruj aktywność sieciową podczas instalacji i pierwszego uruchomienia.

Co zrobić, jeśli znajdziesz prompt injection

1. Zachowaj dowody

Zapisz URL repozytorium, hash commita, surowy markdown, zrzuty ekranu i instrukcje instalacyjne. Zapisz dokładną treść, która była serwowana agentowi.

curl -o evidence.md https://raw.githubusercontent.com/<repo>/<path>

2. Zgłoś to odpowiedzialnie

Jeśli repozytorium jest hostowane na GitHub, użyj zakładki Security, gdy jest dostępna, i prześlij szczegółowy raport z dokładnymi fragmentami, URL-ami i wyjaśnieniem ścieżki ataku.

Jeśli opiekun wydaje się działać złośliwie, eskaluj do GitHub Trust & Safety. Jeśli paczka jest opublikowana w npm lub PyPI, rozważ zgłoszenie jej do rejestru.

3. Ostrożnie ostrzeż społeczność

Jeśli użytkownicy mogą być zagrożeni, podziel się swoimi odkryciami w sposób odpowiedzialny i oparty na faktach. Skup się na dowodach, możliwości odtworzenia i ryzyku dla użytkowników, a nie na spekulacjach.

Publiczna relacja jest często konieczna, ale powinna pomagać ludziom się bronić, a nie wzmacniać taktyki atakującego.

Szerszy problem

To nie chodzi tylko o jedno podejrzane repozytorium.

Wskazuje na szerszą zmianę w bezpieczeństwie oprogramowania: autonomiczne i półautonomiczne agenty do kodowania rozszerzają powierzchnię ataku poza wykonywanie kodu na wykonywanie instrukcji. Złośliwy aktor nie musi już najpierw kompromitować kompilatora, paczki ani kroku budowania. W niektórych przypadkach może wystarczyć skompromitowanie kontekstu agenta.

To poważna zmiana w modelowaniu zagrożeń.

Deweloperzy coraz częściej delegują instalację paczek, edycje kodu, polecenia powłoki i pobieranie dokumentacji do systemów SI. Jeśli te systemy mogą traktować niezaufany tekst jako wskazówki operacyjne, prompt injection staje się praktycznym ryzykiem w łańcuchu dostaw.

Co musi się zmienić

Kilka rzeczy musi szybko się poprawić:

• Frameworki agentów SI potrzebują silniejszego sandboxingu, granic uprawnień i wyraźniejszych punktów kontrolnych zatwierdzania przez człowieka.
• Przeglądy bezpieczeństwa narzędzi deweloperskich muszą uwzględniać ryzyko prompt injection, a nie tylko przegląd kodu źródłowego.
• Platformy takie jak GitHub i rejestry paczek powinny traktować złośliwe instrukcje skierowane do SI jako zgłaszalny problem bezpieczeństwa.
• Deweloperzy muszą rozumieć, że „wklej to do swojego asystenta SI" może być równie ryzykowne jak curl | sudo bash.

Końcowa refleksja

Jeśli korzystasz z agentów SI do kodowania, traktuj dokumentację jako część swojej powierzchni ataku.

Nie zakładaj, że dopracowany README jest bezpieczny. Nie zakładaj, że repozytorium z gwiazdkami jest godne zaufania. I nie zakładaj, że prompt injection jest teoretyczny tylko dlatego, że nie wygląda jak złośliwe oprogramowanie.

Czasem ładunek to nie kod.

Czasem ładunek to instrukcja.

---

Przeanalizowałem repozytorium przywołane w tym artykule 2026-03-31 na podstawie publicznie dostępnych wówczas treści i zgłosiłem problem przez GitHub Security Advisories.

#AISecurity #PromptInjection #CyberSecurity #LLMSecurity #AIAgents #SupplyChainSecurity #DeveloperSecurity