Katalog incydentów bezpieczeństwa kodu i aplikacji AI: co zawiodło, jak i co by to wykryło

Dla kogo jest ten przewodnik.

• CTO i szefowie inżynierii, których zespoły wdrażają kod z Copilota, Cursora, Claude Code albo Gemini CLI i którym zarząd albo klient zadał pytanie, co może pójść nie tak
• Szefowie bezpieczeństwa i platformy, którzy dołożyli do produktu agenta, serwer MCP albo automatyzację obsługi zgłoszeń na LLM i potrzebują konkretnej listy zagrożeń zamiast ogólnej
• Software house'y oddające klientom kod pisany z AI, od których klienci zaczęli wymagać dowodu niezależnego sprawdzenia bezpieczeństwa
• Inżynierowie, którzy czytają biuletyny dostawców po kolei i chcą je mieć w jednym miejscu, pogrupowane według mechanizmu

Co jest wpisem, a co nim nie jest

Gdy w sierpniu 2026 na forum poświęconym bezpieczeństwu padło pytanie, czy ktoś miał już incydent spowodowany przez agenta kodującego, najwyżej oceniona odpowiedź brzmiała: kto miał, ten nie powie, bo NDA i wstyd. Z tej ciszy bierze się kalibrowanie ryzyka według materiałów marketingowych. Katalog poniżej idzie w drugą stronę i przyjmuje 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ą. Wątki praktyków, którzy liczą incydenty z codziennej eksploatacji, istnieją i są dobrym wzorem formatu, ale wątek nie jest źródłem i żaden nie jest tu cytowany.

Trzy granice trzymają tę listę w ryzach. Obejmuje kod i warstwę aplikacyjną: to, co napisał asystent, to, co aplikacja wysyła do modelu i czemu ufa w odpowiedzi, to, co agent ma prawo wywołać. Nie obejmuje infrastruktury, konfiguracji chmury, sieci, testów penetracyjnych ani SOC; to osobne dyscypliny z własnymi katalogami. I nie robi z modelu winowajcy. Każdy wiersz to narzędzie użyte bez sprawdzenia, które postawiłby przed nim proces, i dokładnie dlatego każdy wiersz ma takie sprawdzenie dopisane.

Katalog

Kolejność według daty. Kolumna klasy odsyła do sześciu klas mechanizmów z następnej sekcji. Linki do źródeł są na końcu strony; oceny to wartości CVSS z rekordów CVE tam, gdzie rekord istnieje.

Sześć klas mechanizmów i co je łączy

Nazwy narzędzi zmieniają się co kwartał; mechanizmy nie. Każda klasa poniżej nazywa, co zrobiło narzędzie, czego zabrakło w procesie, i podaje pomiar, jeśli istnieje. Dwa recenzowane badania stoją za klasami dotyczącymi samego generowanego kodu: Pearce i współautorzy (IEEE S&P 2022) wygenerowali Copilotem 1689 programów w 89 scenariuszach słabości i znaleźli podatności w około 40%; Fu i współautorzy (ACM TOSEM 2025) przeanalizowali 733 fragmenty napisane z asystentem znalezione w prawdziwych projektach na GitHubie i wykazali słabości w 29,5% próbek w Pythonie oraz 24,2% w JavaScripcie. Dla zmyślonych pakietów Spracklen i współautorzy (USENIX Security 2025) wygenerowali 576 000 próbek kodu z 16 modeli i znaleźli nieistniejące nazwy pakietów w co najmniej 5,2% odpowiedzi modeli komercyjnych i 21,7% odpowiedzi modeli otwartych, w sumie 205 474 unikalnych zmyślonych nazw.

Co przegląd bezpieczeństwa kodu pisanego z AI sprawdza w każdej klasie

Katalog zaczyna być użyteczny, gdy każda klasa dostaje werdykt dla konkretnego repozytorium: czy to może się zdarzyć u was, tak albo nie, i co tego dowodzi. Lista poniżej to lista kontrolna, którą przegląd wykonuje klasa po klasie. Każdy punkt kończy się artefaktem albo testem, bo werdykt bez nich jest opinią.

• Klasa A: prześledzenie każdej ścieżki, którą niezaufany tekst wchodzi do promptu i po której może iść wywołanie narzędzia; lista każdego narzędzia sięgającego poza proces (sieć, powłoka, zapis pliku, przeglądarka); zestaw testów wstrzyknięć z akcją-kanarkiem uruchamiany w CI na każdej ścieżce; audyt listy dozwolonych adresów wyjściowych pod kątem wygasłych wpisów i symboli wieloznacznych.
• Klasa B: spis tabel i zasobników, a potem sonda na każdym jako klient anonimowy i jako użytkownik o niskich uprawnieniach; skan zbudowanej paczki klienta pod kątem kluczy, nie tylko repozytorium; porównanie domyślnych ustawień frameworka odtworzonych przez asystenta (CORS, flagi weryfikacji, wypisywanie błędów) z konfiguracją produkcyjną.
• Klasa C: diff pliku lockfile w każdym pull requeście napisanym z asystentem; sprawdzenie każdego nowego pakietu w rejestrze pod kątem wieku, wydawcy i historii pobrań; lista dozwolonych pakietów dla środowiska uruchomieniowego i blokada poleceń instalacji, które asystent wpisał do dokumentacji.
• Klasa D: lista wszystkich danych dostępowych w środowisku agenta razem ze środowiskiem, do którego należą; oddzielenie produkcji od wszystkiego, do czego agent sięga; operacje destrukcyjne za jawnym potwierdzeniem i jedna próba przywracania z zapisanym czasem trwania.
• Klasa E: znalezienie każdego miejsca, w którym wynik modelu jest wykonywany albo wysyłany jako zapytanie; rola tylko do odczytu i lista dozwolonych instrukcji dla generowanego SQL; usunięcie exec generowanego kodu z każdej ścieżki dostępnej dla użytkownika; piaskownica dla tego, co zostaje.
• Klasa F: inwentaryzacja serwerów MCP, rozszerzeń i tokenów z ich zakresami; zawężenie każdego do zadania, któremu służy; hash zatwierdzonych definicji narzędzi i ponowna zgoda przy zmianie; przypięte wersje i przegląd aktualizacji jak przy aktualizacji zależności.
• Retest: po poprawkach każda klasa dostaje ten sam test jeszcze raz, a wynik zapisuje się obok pierwotnego werdyktu. Ta para wyników jest dowodem, który może przeczytać klient albo zarząd.

Gdzie to się psuje i co z tym robimy.

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

   Agent dostaje do kontekstu zgłoszenie, ticket, README albo mail, bo tego potrzebuje do pracy, a model nie ma pewnego sposobu na odróżnienie cytowanego tekstu od prośby użytkownika. Gdy w tej samej sesji jest dostępne 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ę, którą niezaufany tekst wchodzi do promptu, i wypisujemy każde narzędzie osiągalne z tej sesji. Tam, gdzie się spotykają, albo zdejmujemy narzędzie wychodzące, albo stawiamy je za zgodą pokazującą pełną akcję, albo oznaczamy treść jako dane w strukturze promptu. Potem uruchamiamy zestaw testów wstrzyknięć z akcją-kanarkiem na każdej ścieżce i zostawiamy go w waszym CI.

   Co zostaje u was: mapa niezaufanych treści i osiągalnych narzędzi ścieżka po ścieżce, razem z zestawem testów wstrzyknięć i wynikiem per ścieżka
2. 2
   Wygenerowana konfiguracja backendu trafia na produkcję w stanie, w jakim powstała

   Asystent stawia backend według wzorca, który zna najlepiej: klucz w kliencie, reguły dostępu wyłączone albo zbyt szerokie, wypisywanie błędów włączone. W demie to działa, bo demo ma jednego użytkownika. CVE dla Lovable i ekspozycja Moltbooka to ten sam mechanizm w dwóch skalach i w obu przypadkach stanowisko dostawcy brzmiało, że reguły dostępu są po stronie klienta.

   Co z tym robimy

   Spisujemy każdą tabelę i zasobnik, potem sondujemy 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 przechodzi na stronę serwera, a sonda biegnie ponownie, aż nie zwróci nic. Sonda zostaje jako sprawdzenie przed publikacją.

   Co zostaje u was: macierz dostępu tabela po tabeli z wynikiem sondy klientem anonimowym przed i po, plus sonda wpięta w proces wydawania
3. 3
   Nazwy pakietów są zaufane, bo wyglądają zwyczajnie

   Asystent pisze linię instalacji z wiarygodną nazwą, której nie ma w rejestrze, 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 tej linii zaufał. Przypadek huggingface-cli pokazuje nazwę, która dotarła do dokumentacji prawdziwego repozytorium, zanim ktokolwiek sprawdził rejestr.

   Co z tym robimy

   Robimy diff pliku lockfile każdej zmiany napisanej z asystentem, sprawdzamy każdy nowy pakiet w rejestrze pod kątem wieku, wydawcy i historii, i zamieniamy to sprawdzenie w regułę przeglądu. Polecenia instalacji, które asystent wpisał do dokumentacji, dostają to samo.

   Co zostaje u was: raport pochodzenia zależności za okres pracy z asystentem, plus sprawdzenie w rejestrze jako reguła CI
4. 4
   Destrukcyjne polecenia idą, bo potwierdzenie było wyłączone

   Turbo, YOLO, auto-zgoda: ten tryb istnieje, bo potwierdzenia spowalniają demo. W tym trybie czyszczenie pamięci podręcznej, które trafia w złą ścieżkę, albo reset bazy wydany w czasie zamrożenia kodu, wykonują się z prędkością agenta. Oba wpisy klasy D w katalogu wydarzyły się, gdy agent miał dane dostępowe, których do zadania nigdy nie potrzebował.

   Co z tym robimy

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

   Co zostaje u was: mapa danych dostępowych per agent i środowisko, lista operacji za bramką i zapis próby przywracania z czasem trwania
5. 5
   Definicja narzędzia się zmienia i nikt nie pyta ponownie

   Serwer MCP albo rozszerzenie zostały zatwierdzone raz. Definicja żyje we wspólnym 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: podmienione polecenie na gałęzi i niezatwierdzony kod w opublikowanej wersji.

   Co z tym robimy

   Inwentaryzujemy serwery MCP, rozszerzenia i tokeny z ich zakresami, zawężamy każdy zakres do zadania, liczymy hash 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 per zadanie, hashe zatwierdzonych definicji i reguła ponownej zgody w waszej konfiguracji

Co zostaje u was.

• Mapa incydentów na repozytorium: werdykt per klasa mechanizmu dla waszych repozytoriów i integracji agentów, z dowodem za każdym werdyktem
• Lista kontrolna per klasa, wypełniona dla waszego stosu, z artefaktem albo testem zamykającym każdy punkt
• Zestaw testów wstrzyknięć z akcjami-kanarkami, wpięty w CI, z wynikiem per ścieżka niezaufanej treści
• Macierz dostępu do tabel i zasobników z wynikiem sondy klientem anonimowym przed i po
• Raport pochodzenia zależności za okres pracy z asystentem i sprawdzenie w rejestrze jako reguła przeglądu
• Inwentarz narzędzi: serwery MCP, rozszerzenia i tokeny z zakresem per zadanie, hashe definicji i reguła ponownej zgody
• Zapis retestu: każda klasa sprawdzona ponownie po poprawkach, obok pierwotnego werdyktu

Jak pracujemy.

1. 1
   1. Mapowanie

   Przechodzimy repozytoria i integracje agentów z seniorem 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 agenta, wynik modelu do SQL albo exec, zakresy narzędzi.

   Tydzień 1
2. 2
   2. Werdykty

   Wykonujemy listę kontrolną klasa po klasie: testy wstrzyknięć, sondy klientem anonimowym, sprawdzenia pliku lockfile i rejestru, inwentarze danych dostępowych i narzędzi. Każda klasa dostaje tak albo nie z dowodem, a znaleziska, które z tego wychodzą, mają reprodukcję.

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

   Naprawiamy znaleziska razem z waszym zespołem i zamieniamy każdy zamknięty punkt w bramkę: sondę, zestaw testów, regułę rejestru, sprawdzenie hasha. Każdą bramkę raz celowo uruchamiamy, żeby udowodnić, że działa.

   Tydzień 2-3
4. 4
   4. Retest i przekazanie

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

   Tydzień 3

Pozostałe strony z tej serii.

Gdzie to zamienia się w usługę.

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)