Katalog incydentów bezpieczeństwa w kodzie pisanym z AI: co zawiodło i jaka kontrola by to wykryła

Kto skorzysta z tego przewodnika.

• CTO i wiceprezesi ds. inżynierii, których zespoły wdrażają kod z Copilota, Cursora, Claude Code albo Gemini CLI i których zarząd albo klient zapytał, co może pójść nie tak
• Szefowie bezpieczeństwa i zespołów platformowych, którzy dodali agenta w aplikacji, serwer MCP albo automatyzację wsparcia na LLM i potrzebują konkretnej listy zagrożeń zamiast ogólnej
• Software house'y, które dostarczają klientom kod pisany z AI, a klienci proszą teraz o dowód niezależnego sprawdzenia bezpieczeństwa
• Inżynierowie, którzy czytają biuletyny dostawców jeden po drugim i chcą mieć je w jednym miejscu, posortowane według mechanizmu

Co jest wpisem, a co nim nie jest

O cudzych incydentach z agentami kodującymi zespoły słyszą rzadko: NDA i wstyd trzymają je poza publicznym obiegiem, więc zespoły polegają na deklaracjach dostawców. Katalog poniżej idzie odwrotną drogą i wymienia tylko to, co da się sprawdzić u źródła: rekord CVE, biuletyn bezpieczeństwa dostawcy, publiczne oświadczenie kierownictwa dostawcy albo recenzowany pomiar z opublikowaną metodą. Relacja prasowa wchodzi tylko wtedy, gdy przytacza publiczne oświadczenie dostawcy, a wiersz to oznacza. Wpisy są trzech rodzajów: incydenty z potwierdzoną szkodą, podatności z rekordem CVE albo biuletynem oraz demonstracje badaczy; kolumna Skutek mówi, o który rodzaj chodzi. Wątki praktyków, którzy liczą incydenty z codziennej pracy, są przydatne jako format, ale wątek nie jest źródłem i żaden nie jest tu cytowany.

Trzy granice trzymają listę w ryzach. Obejmuje kod i warstwę aplikacji: co napisał asystent, co aplikacja wysyła do modelu i czemu ufa w odpowiedzi, co agent ma prawo wywołać. Nie obejmuje infrastruktury, konfiguracji chmury, bezpieczeństwa sieci, testów penetracyjnych ani SOC; to osobne dyscypliny z własnymi katalogami. Nie traktuje też modelu jak winowajcy. Każdy wiersz to narzędzie użyte bez kontroli, którą postawiłby przed nim proces. Właśnie dlatego każdy wiersz ma dopisaną kontrolę.

Katalog

Posortowany według daty publikacji źródła (rekordu CVE, biuletynu, raportu albo badania). Kolumna klasy używa sześciu klas mechanizmów zdefiniowanych w następnej sekcji. Odnośniki do źródeł są na końcu strony. Oceny ważności to wartości CVSS z rekordów CVE tam, gdzie rekord istnieje; przy ForcedLeak wartość pochodzi z raportu Noma Security.

Sześć klas mechanizmów i co łączy wpisy w każdej z nich

Nazwy narzędzi się zmieniają, mechanizmy się powtarzają. Każda klasa poniżej nazywa, co zrobiło narzędzie, czego brakowało procesowi i jaki pomiar za tym stoi, jeśli istnieje. Dwa recenzowane badania kotwiczą klasy dotyczące samego generowanego kodu: Pearce i współautorzy (IEEE S&P 2022) wygenerowali Copilotem 1 689 programów w 89 scenariuszach słabości i uznali około 40% za podatne; Fu i współautorzy (ACM TOSEM 2025) przeanalizowali 733 fragmenty napisane przez asystenta znalezione w prawdziwych projektach na GitHubie i zgłosili słabości w 29,5% próbki w Pythonie i 24,2% w JavaScripcie.

Co sprawdza przegląd bezpieczeństwa kodu pisanego przez AI, klasa po klasie

Katalog staje się użyteczny, gdy każda klasa dostaje wynik dla konkretnej bazy kodu: wynik konkretnego testu, sprawdzony zakres i granice wniosku. Lista poniżej to lista kontrolna, którą Przegląd bezpieczeństwa kodu pisanego przez AI wykonuje dla każdej klasy. Każdy punkt kończy się artefaktem albo testem, bo wynik bez nich jest opinią.

• Klasa A. Prześledźcie każdą ścieżkę, którą niezaufany tekst wchodzi do promptu i po której może nastąpić wywołanie narzędzia. Wypiszcie każde narzędzie, które sięga poza proces: sieć, powłoka, zapis pliku, przeglądarka. Zbudujcie zestaw testów wstrzyknięć z działaniem kanarkowym i uruchamiajcie go w CI na każdej ścieżce. Przejrzyjcie listę dozwolonych adresów wychodzących pod kątem wygasłych wpisów i symboli wieloznacznych.
• Klasa B. Wypiszcie tabele i zasobniki, a potem sprawdźcie każdy z nich jako klient anonimowy i jako użytkownik o niskich uprawnieniach. Przeskanujcie zbudowaną paczkę klienta pod kątem kluczy uprzywilejowanych, nie tylko repozytorium. Porównajcie domyślne ustawienia frameworka odtworzone przez asystenta (CORS, flagi weryfikacji, wyjście debugowania) z konfiguracją produkcyjną.
• Klasa C. Porównujcie plik blokady w każdym pull requeście napisanym z asystentem. Sprawdzajcie każdy nowy pakiet pod kątem wieku w rejestrze, wydawcy i historii pobrań. Utrzymujcie listę dozwolonych dla środowiska uruchomieniowego i blokadę poleceń instalacji, które asystent wpisuje do dokumentacji.
• Klasa D. Wypiszcie każde dane dostępowe w środowisku agenta razem ze środowiskiem, do którego należą. Oddzielcie produkcję od wszystkiego, do czego agent sięga. Postawcie operacje destrukcyjne za jawnym potwierdzeniem i przećwiczcie przywracanie raz, z zapisanym czasem, ile trwało.
• Klasa E. Znajdźcie każdy punkt, w którym wynik modelu jest wykonywany albo odpytuje bazę. Dajcie generowanemu SQL rolę ograniczoną do tabel z zadania, bez zapisu, oraz listę dozwolonych instrukcji. Usuńcie wykonywanie wygenerowanego kodu z każdej ścieżki dostępnej użytkownikom. To, co zostaje, zamknijcie w piaskownicy.
• Klasa F. Zinwentaryzujcie serwery MCP, rozszerzenia i tokeny razem z ich zakresami. Zawęźcie każdy do zadania, któremu służy. Liczcie skróty zatwierdzonych definicji narzędzi i wymagajcie ponownej zgody przy zmianie. Przypnijcie wersje i przeglądajcie aktualizacje jak aktualizacje zależności.
• Ponowny test. Po poprawkach każda klasa dostaje ten sam test jeszcze raz, a wynik jest zapisany obok pierwotnego. Para wyników to dowód, który może przeczytać klient albo zarząd.

Co może pójść nie tak i co z tym robimy.

1. 1
   Treść, którą czyta agent, jest traktowana jak polecenie

   Agent dostaje do kontekstu zgłoszenie do wsparcia, zgłoszenie w repozytorium, README albo e-mail, bo tego wymaga zadanie, a model nie ma niezawodnego sposobu, żeby odróżnić cytowany tekst od prośby użytkownika. Gdy w tej samej sesji dostępne jest narzędzie sięgające poza proces, tekst może je wywołać. Każdy wpis klasy A w katalogu ma ten kształt, od GitLab Duo po Antigravity, a poprawki dostawców były granicami wokół narzędzi, nie lepszymi modelami.

   Co z tym robimy

   Mapujemy każdą ścieżkę wejścia niezaufanego tekstu do promptu i wypisujemy każde narzędzie osiągalne z tej sesji. Tam, gdzie jedno spotyka drugie, usuwamy narzędzie wychodzące albo stawiamy je za zgodą pokazującą pełne działanie. Oznaczenie treści jako danych w strukturze promptu zostaje środkiem pomocniczym, nie zamiennikiem kontroli wykonywanej poza modelem. Potem uruchamiamy zestaw testów wstrzyknięć z działaniem kanarkowym na każdej ścieżce i przekazujemy go do waszego CI.

   Co zostaje u was: mapa niezaufanej treści i osiągalnych narzędzi ścieżka po ścieżce, z zestawem testów wstrzyknięć i wynikami dla każdej ścieżki
2. 2
   Wygenerowany domyślny backend idzie na produkcję w stanie, w jakim powstał

   Asystent stawia backend według wzorca, który zna najlepiej: klucz po stronie klienta, reguły dostępu wyłączone albo luźne, wyjście debugowania włączone. W demo to działa, bo demo ma jednego użytkownika. CVE Lovable i wyciek Moltbook to ten sam mechanizm w dwóch skalach i w obu przypadkach dostawca stał na stanowisku, że reguły dostępu należą do klienta.

   Co z tym robimy

   Wypisujemy każdą tabelę i zasobnik, potem sprawdzamy każdy z nich jako klient anonimowy i jako użytkownik o niskich uprawnieniach, a zbudowaną paczkę skanujemy pod kątem kluczy. Każda tabela, która nie przechodzi, dostaje politykę, każdy klucz uprzywilejowany przenosi się na stronę serwera, a klucze publiczne zostają tylko tam, gdzie tabele mają reguły dostępu. Test uruchamia się ponownie, aż nic nie zwróci. Potem zostaje jako kontrola przed publikacją.

   Co zostaje u was: macierz dostępu tabela po tabeli z wynikiem sondy klientem anonimowym przed poprawką i po niej oraz sonda wpięta w potok wydawania
3. 3
   Nazwy pakietów zyskują zaufanie, bo wyglądają zwyczajnie

   Asystent pisze linię instalacji z wiarygodną nazwą, która nie istnieje, a badanie Spracklena i współautorów pokazuje, że te same zmyślone nazwy powtarzają się między promptami. Kto zarejestruje taką nazwę, dostaje instalacje z każdego projektu, który zaufał tej linii. Przypadek huggingface-cli pokazuje, jak nazwa trafiła do dokumentacji prawdziwego repozytorium, zanim ktokolwiek sprawdził rejestr.

   Co z tym robimy

   Porównujemy plik blokady w każdej zmianie napisanej z asystentem, sprawdzamy każdy nowy pakiet w rejestrze pod kątem wieku, wydawcy i historii i zamieniamy tę kontrolę w regułę przeglądu. Polecenia instalacji, które asystent wpisał do dokumentacji, przechodzą to samo.

   Co zostaje u was: raport pochodzenia zależności za okres pracy z AI oraz kontrola rejestru jako reguła CI
4. 4
   Destrukcyjne polecenia wykonują się, bo potwierdzenie było wyłączone

   Turbo, YOLO, automatyczna zgoda: tryby, w których agent wykonuje polecenia bez potwierdzeń. W takim trybie czyszczenie pamięci podręcznej, które trafia w złą ścieżkę, albo reset bazy wydany w czasie zamrożenia kodu wykonuje się z prędkością agenta. W obu wpisach klasy D agent miał dostęp szerszy niż zadanie: do bazy produkcyjnej i do całego dysku.

   Co z tym robimy

   Wypisujemy każde dane dostępowe, do których agent sięga, razem ze środowiskiem, do którego należą, usuwamy z tej listy produkcję i stawiamy operacje destrukcyjne za jawną bramką. Potem ćwiczymy przywracanie raz i zapisujemy, ile trwało.

   Co zostaje u was: mapa danych dostępowych dla każdego agenta i środowiska, lista operacji za bramką oraz zapis próby przywracania z czasem trwania
5. 5
   Definicja narzędzia się zmienia, a nikt nie pyta ponownie

   Serwer MCP albo rozszerzenie zostało zatwierdzone raz. Definicja leży we współdzielonym repozytorium albo aktualizuje się sama, a zgoda nie idzie za zmianą. Obejście ponownej zgody w Cursorze i wydanie rozszerzenia Amazon Q pokazują dwa końce tej samej drogi: podmienione polecenie na gałęzi i niezatwierdzony kod w opublikowanej wersji.

   Co z tym robimy

   Inwentaryzujemy serwery MCP, rozszerzenia i tokeny razem z zakresami, zawężamy każdy zakres do zadania, liczymy skrót każdej zatwierdzonej definicji i wymagamy ponownej zgody przy zmianie. Wersje zostają przypięte, a aktualizacje przechodzą ten sam przegląd co aktualizacje zależności.

   Co zostaje u was: inwentarz narzędzi z zakresem dla każdego zadania, skróty zatwierdzonych definicji i reguła ponownej zgody w waszej konfiguracji

Co zostaje u was.

• Mapowanie incydentów na bazę kodu: wynik testu dla każdej klasy mechanizmu w waszych repozytoriach i integracjach agentów, z dowodami i zakresem sprawdzenia
• Lista kontrolna dla każdej klasy, wypełniona dla waszego stosu, z artefaktem albo testem, który zamyka każdy punkt
• Zestaw testów wstrzyknięć z działaniami kanarkowymi, wpięty w CI, z wynikami dla każdej ścieżki niezaufanej treści
• Macierz dostępu do tabel i zasobników z wynikiem sondy klientem anonimowym, przed poprawkami i po nich
• Raport pochodzenia zależności za okres pracy z AI oraz kontrola rejestru jako reguła przeglądu
• Inwentarz narzędzi: serwery MCP, rozszerzenia i tokeny z zakresem dla każdego zadania, skróty definicji i reguła ponownej zgody
• Zapis ponownego testu: każda klasa przetestowana ponownie po poprawkach, z wynikiem obok pierwotnego

Jak pracujemy.

1. 1
   1. Mapowanie

   Przechodzimy repozytoria i integracje agentów z doświadczonym inżynierem z waszej strony i zaznaczamy, gdzie może wystąpić każda klasa mechanizmu: ścieżki niezaufanej treści, wygenerowane reguły backendu, nowe zależności, dane dostępowe agentów, wynik modelu w SQL albo w wykonaniu kodu, zakresy narzędzi.

   Tydzień 1
2. 2
   2. Werdykty

   Wykonujemy listę kontrolną dla każdej klasy: testy wstrzyknięć, sondy klientem anonimowym, kontrole pliku blokady i rejestru, inwentarze danych dostępowych i narzędzi. Każda klasa dostaje wynik testu z dowodami i zakresem sprawdzenia, a każde ustalenie ma sposób odtworzenia.

   Tydzień 1-2
3. 3
   3. Poprawki i bramki

   Usuwamy wykryte błędy razem z waszym zespołem i zamieniamy każdy zamknięty punkt w bramkę: sondę, zestaw testów, regułę rejestru, kontrolę skrótów. Każdą bramkę uruchamiamy raz celowo, żeby dowieść, że działa.

   Tydzień 2-3
4. 4
   4. Ponowny test i przekazanie

   Powtarzamy test każdej klasy, zapisujemy wynik obok pierwotnego i przekazujemy mapowanie, listy kontrolne i bramki w waszym potoku. Katalog na tej stronie jest punktem odniesienia, od którego zaczyna się następny przegląd.

   Tydzień 3, zależnie od liczby repozytoriów i integracji

Pozostałe strony z tej serii.

Usługi, które to wdrażają.

Skąd pochodzą daty i liczby.

• CVE-2025-53773, zdalne wykonanie kodu w GitHub Copilot i Visual Studio (Microsoft, sierpień 2025)
• Embrace The Red, RCE w GitHub Copilot przez wstrzyknięcie promptu: settings.json i chat.tools.autoApprove
• CVE-2025-32711, ujawnienie informacji w Microsoft 365 Copilot, EchoLeak (czerwiec 2025)
• CVE-2025-54135, wstrzyknięcie promptu w Cursorze przez pliki specjalne MCP, poprawka w 1.3.9 (advisory GitHub)
• CVE-2025-54136, zmiana definicji MCP w Cursorze omija ponowną zgodę (advisory GitHub)
• CVE-2025-54794, obejście ograniczenia ścieżek w Claude Code, poprawka w 0.2.111 (advisory GitHub)
• CVE-2025-6514, wstrzyknięcie polecenia systemowego w mcp-remote z niezaufanych serwerów MCP (JFrog Security Research)
• CVE-2024-5565, wstrzyknięcie promptu w Vanna.AI prowadzące do zdalnego wykonania kodu (JFrog Security Research)
• CVE-2023-36189, SQL injection w LangChain SQLDatabaseChain
• CVE-2025-48757, niewystarczające row-level security w aplikacjach generowanych w Lovable; ujawnienie Matta Palmera
• Legit Security, zdalne wstrzyknięcie promptu w GitLab Duo (ukryta treść, wyprowadzenie prywatnego kodu)
• Invariant Labs, serwer GitHub MCP: dane z prywatnego repozytorium wyprowadzone przez publiczne zgłoszenie
• General Analysis, Supabase MCP z Cursorem: od zgłoszenia do wsparcia do wycieku integration_tokens
• Dokumentacja Supabase, bezpieczeństwo serwera MCP: wstrzyknięcie promptu, tryb tylko do odczytu, zakres projektu, grupy funkcji
• Biuletyn bezpieczeństwa AWS-2025-015, Amazon Q Developer dla VS Code 1.84.0
• Tracebit, Gemini CLI: wykonanie kodu i wyprowadzenie danych przez README i obejście listy dozwolonych, poprawka w 0.1.14
• Noma Security, ForcedLeak: wyprowadzenie danych CRM z Salesforce Agentforce przez Web-to-Lead i wygasłą domenę z listy dozwolonych
• PromptArmor, Google Antigravity wyprowadza dane: ukryty tekst na stronie, .env przez cat, podagent przeglądarki
• The Register, Google Antigravity w trybie Turbo kasuje dysk użytkownika; Google potwierdza postępowanie (grudzień 2025)
• Fortune, Replit Agent kasuje bazę produkcyjną w czasie zamrożenia kodu; oświadczenie prezesa i zapowiedziane poprawki (lipiec 2025)
• Wiz Research, Moltbook: odsłonięta baza Supabase, 1,5 mln tokenów API (luty 2026)
• Lasso Security, halucynacje pakietów: eksperyment huggingface-cli (marzec 2024)
• Spracklen i współautorzy, We Have a Package for You! Halucynacje pakietów w LLM generujących kod, USENIX Security 2025 (arXiv 2406.10279)
• Fu i współautorzy, Słabości bezpieczeństwa kodu z Copilota w projektach na GitHubie, ACM TOSEM 2025 (arXiv 2310.02059)
• Pearce i współautorzy, Asleep at the Keyboard? Bezpieczeństwo kodu z GitHub Copilota, IEEE S&P 2022 (arXiv 2108.09293)