Archiwa: LLM - Strona 11 z 20 - Security Bez Tabu

CrowdStrike 2026: AI, Tożsamość I Nowe Ataki

Rok niewidzialnego przeciwnika: czego raport CrowdStrike 2026 uczy o AI, tożsamości i nowych ścieżkach ataku

Zobaczmy, co się dzieje, gdy napastnik nie wrzuca EXE na stację, nie zostawia klasycznego droppera i nie wygląda jak ktoś, kto właśnie „wszedł do środka”. Dzwoni na help desk. Resetuje hasło. Rejestruje urządzenie w chmurze. Przegląda SharePointa. Odpala tymczasową VM-kę w vCenter. A potem szyfruje dane z boku przez SMB albo wyciąga je przez legalny kanał SaaS. Właśnie dlatego raport CrowdStrike 2026 Global Threat Report warto czytać nie jako kolejną publikację „o AI”, tylko jako opis zmiany modelu ataku.

Czytaj dalej „CrowdStrike 2026: AI, Tożsamość I Nowe Ataki”

LLM-y w atakach na infrastrukturę krytyczną: incydent wodociągów w Meksyku ujawnia nowy etap zagrożeń OT

Cybersecurity news

Wprowadzenie do problemu / definicja

Wykorzystanie dużych modeli językowych (LLM) w cyberatakach przestaje być wyłącznie hipotezą analizowaną przez branżę bezpieczeństwa. Opisywany przypadek związany z operatorem wodociągów i kanalizacji w aglomeracji Monterrey w Meksyku pokazuje, że generatywna AI może realnie wspierać działania ofensywne wymierzone w środowiska infrastruktury krytycznej.

Z perspektywy bezpieczeństwa OT i ICS to istotna zmiana. Modele LLM mogą bowiem obniżać próg wejścia dla napastników, przyspieszać rekonesans, pomagać w analizie dokumentacji technicznej oraz wspierać budowę ścieżki przejścia z klasycznej sieci IT do systemów operacyjnych odpowiedzialnych za procesy przemysłowe.

W skrócie

Analizowany incydent dotyczył kompromitacji środowiska IT operatora wodociągów, która następnie eskalowała w kierunku infrastruktury OT. Kampania miała trwać od grudnia 2025 do lutego 2026 i obejmowała wykorzystanie komercyjnych modeli LLM do planowania działań, analizy środowiska, przetwarzania zebranych informacji oraz tworzenia złośliwych skryptów.

Nie potwierdzono skutecznego przejęcia systemów OT, jednak sam przebieg zdarzenia pokazał, że AI może być praktycznym akceleratorem działań intruza. To szczególnie ważne w kontekście środowisk przemysłowych, gdzie nawet częściowy sukces na etapie rozpoznania może znacząco zwiększyć ryzyko dla ciągłości działania usług publicznych.

  • atak rozpoczął się w warstwie IT i zmierzał w kierunku OT,
  • LLM-y wspierały rekonesans, analizę i przygotowanie narzędzi,
  • AI mogła pomóc mniej doświadczonym operatorom poruszać się po środowisku przemysłowym,
  • sam incydent potwierdził rosnące znaczenie zagrożeń na styku IT i OT.

Kontekst / historia

Incydent wpisuje się w szerszy trend konwergencji zagrożeń IT i OT. W ostatnich latach organizacje odpowiedzialne za infrastrukturę krytyczną coraz częściej mierzą się z sytuacją, w której kompromitacja zasobów korporacyjnych staje się pierwszym etapem działań prowadzących do rozpoznania lub potencjalnego wpływu na systemy sterowania przemysłowego.

Znaczenie tego przypadku wynika z jeszcze jednego powodu. Atak na operatora wodociągów nie był przedstawiany jako odosobnione zdarzenie, lecz jako element szerszej aktywności wymierzonej w meksykańskie podmioty publiczne i infrastrukturalne. To sugeruje, że napastnicy testują lub rozwijają metody, które można przenosić pomiędzy różnymi organizacjami i sektorami.

Historycznie dyskusja o zagrożeniach dla OT koncentrowała się na phishingu, kradzieży poświadczeń, ruchu bocznym oraz nadużyciu zdalnego dostępu. Nowością jest aktywne wykorzystanie modeli LLM do wspierania decyzji operacyjnych i generowania artefaktów używanych podczas intruzji. To przesuwa debatę z pytania o to, czy AI będzie wykorzystywana przez napastników, do pytania o to, jak bardzo zmienia ona tempo i dostępność takich operacji.

Analiza techniczna

Z opisu incydentu wynika, że modele LLM zostały użyte w kilku kluczowych obszarach. Pierwszym był rekonesans i zrozumienie środowiska ofiary. Model miał pomagać w analizie dokumentacji dostawców, interpretacji elementów związanych ze środowiskiem SCADA oraz identyfikacji zasobów istotnych z punktu widzenia dostępu do OT.

To ważne, ponieważ intruz działający początkowo w sieci IT nie zawsze potrafi szybko rozpoznać, które hosty, usługi, katalogi lub dokumenty wskazują na obecność systemów przemysłowych. LLM może tu pełnić rolę asystenta analitycznego, który skraca czas potrzebny na interpretację znalezionych artefaktów.

Drugim obszarem było tworzenie i udoskonalanie narzędzi ofensywnych. Analizowane artefakty miały obejmować znaczną liczbę złośliwych skryptów wygenerowanych lub rozwijanych przy wsparciu AI. W praktyce oznacza to możliwość szybszego pisania kodu, modyfikowania payloadów i iteracyjnego dostosowywania logiki działania do reakcji środowiska ofiary.

Trzecie zastosowanie dotyczyło analizy operacyjnej i przetwarzania zebranych danych. Modele mogły wspierać porządkowanie wyników rekonesansu, generowanie treści w języku hiszpańskim oraz planowanie kolejnych kroków intruzji. Taki mechanizm redukuje ilość pracy ręcznej i pozwala prowadzić kampanię w sposób bardziej uporządkowany.

Szczególnie niepokojącym elementem była pomoc AI w identyfikacji domyślnych i znanych danych logowania, które mogły zostać wykorzystane w próbach uzyskania dostępu do systemów. W środowiskach OT, gdzie nadal występują przestarzałe urządzenia, słabo zarządzane konta i ograniczona segmentacja, taka funkcja może wyraźnie zwiększać skuteczność działań napastnika.

  • rekonesans środowiska IT i OT,
  • analiza dokumentacji technicznej i artefaktów SCADA,
  • tworzenie oraz modyfikacja skryptów ofensywnych,
  • przetwarzanie danych z rozpoznania i planowanie kolejnych kroków,
  • wsparcie w identyfikacji poświadczeń i potencjalnych punktów wejścia.

Na poziomie taktycznym przypadek ten potwierdza również, że napastnicy nie muszą posiadać pełnej wiedzy o ICS na początku operacji. Jeśli model potrafi pomóc w interpretacji nazw hostów, interfejsów HMI, komponentów SCADA czy schematów zdalnego dostępu, to bariera kompetencyjna wejścia w obszar OT istotnie maleje.

Konsekwencje / ryzyko

Najważniejszą konsekwencją nie jest sam fakt wygenerowania złośliwego kodu, lecz możliwość szybszego przejścia od kompromitacji środowiska IT do celowania w zasoby OT. W sektorze wodociągów i kanalizacji potencjalne skutki takiego scenariusza obejmują zakłócenie procesów uzdatniania, dystrybucji, monitoringu oraz utratę widoczności operacyjnej.

Z punktu widzenia obrony AI działa tutaj jako mnożnik efektywności. Atakujący szybciej analizuje środowisko, sprawniej przygotowuje skrypty, skuteczniej interpretuje dane i łatwiej adaptuje techniki do reakcji systemów bezpieczeństwa. To zwiększa tempo operacji i skraca czas dostępny na detekcję oraz reakcję.

Ryzyko strategiczne rośnie szczególnie tam, gdzie organizacja ma ograniczoną widoczność w OT. Jeśli monitoring obejmuje głównie sieć korporacyjną, a środowisko przemysłowe funkcjonuje przy niskim poziomie telemetrii, moment przejścia intruza z warstwy IT do operacyjnej może zostać przeoczony.

  • większa skuteczność rekonesansu i ruchu bocznego,
  • skrócenie czasu potrzebnego do przygotowania ataku,
  • obniżenie progu wejścia dla mniej doświadczonych napastników,
  • wzrost ryzyka dla ciągłości działania usług publicznych,
  • trudniejsza analiza incydentu przy niskiej widoczności w OT.

Rekomendacje

Organizacje odpowiedzialne za infrastrukturę krytyczną powinny potraktować ten przypadek jako sygnał do rewizji modelu ochrony na styku IT i OT. Priorytetem pozostaje ograniczenie możliwości niekontrolowanego przejścia z sieci biurowej do przemysłowej poprzez ścisłą segmentację, kontrolę przepływów oraz egzekwowanie zasady najmniejszych uprawnień.

Drugim filarem powinna być pełna inwentaryzacja zasobów OT, obejmująca stacje inżynierskie, serwery SCADA, interfejsy HMI, systemy zdalnego dostępu i połączenia z dostawcami. Bez rzetelnej wiedzy o tym, jakie systemy faktycznie istnieją i które z nich są osiągalne z IT, skuteczna detekcja pozostaje ograniczona.

Równie ważny jest monitoring. Warto wdrażać telemetrię pozwalającą wykrywać nietypowy rekonesans, enumerację udziałów sieciowych, próby użycia domyślnych poświadczeń, nietypowy dostęp do dokumentacji technicznej oraz anomalie w zdalnym dostępie do urządzeń przemysłowych.

Istotny pozostaje także przegląd zarządzania poświadczeniami. W środowiskach przemysłowych należy eliminować konta współdzielone, domyślne hasła, niezmienione dane serwisowe oraz nadmierne uprawnienia partnerów zewnętrznych. Tam, gdzie to możliwe, należy wdrażać MFA, sejfy haseł uprzywilejowanych i rotację poświadczeń po pracach serwisowych.

  • wdrożenie ścisłej segmentacji między IT i OT,
  • pełna inwentaryzacja aktywów przemysłowych,
  • monitoring anomalii wskazujących na zainteresowanie zasobami OT,
  • usunięcie domyślnych i współdzielonych poświadczeń,
  • kontrola i rejestrowanie zdalnego dostępu,
  • ćwiczenia SOC, IR i zespołów OT dla scenariuszy z użyciem AI przez intruza.

Podsumowanie

Incydent dotyczący operatora wodociągów w Meksyku pokazuje, że modele LLM stają się praktycznym narzędziem wspierającym operacje ofensywne przeciwko infrastrukturze krytycznej. Największym problemem nie jest wyłącznie automatyzacja tworzenia skryptów, ale zdolność AI do przyspieszania rekonesansu, interpretacji środowiska OT oraz budowania ścieżki dostępu z sieci IT do systemów przemysłowych.

Dla obrońców oznacza to konieczność zwiększenia widoczności w OT, szybszego wykrywania działań przygotowawczych oraz zaostrzenia kontroli dostępu zdalnego. Ataki wspierane przez AI nie zastępują klasycznych technik intruzji, ale sprawiają, że stają się one szybsze, tańsze i bardziej dostępne dla szerszego grona napastników.

Źródła

  1. Infosecurity Magazine — OpenAI and Anthropic LLMs Used in Critical Infrastructure Cyber-Attack, Warns Dragos — https://www.infosecurity-magazine.com/news/llm-critical-infrastructure/
  2. Dragos — OT Threat Landscape 2026: What Defenders Need to Know — https://www.dragos.com/blog/ot-threat-landscape-2026
  3. Dragos — Dragos 2026 OT Cybersecurity Report Year in Review — https://hub.dragos.com/hubfs/2026_YIR_ExecutiveBriefing%20O_G.pdf?hsLang=en
  4. SecurityWeek — Claude AI Guided Hackers Toward OT Assets During Water Utility Intrusion — https://www.securityweek.com/claude-ai-guided-hackers-toward-ot-assets-during-water-utility-intrusion/amp/
  5. Cyber Risk Leaders — Dragos report outlines early AI-assisted targeting of OT during IT intrusion — https://cyberriskleaders.com/dragos-report-outlines-early-ai-assisted-targeting-of-ot-during-it-intrusion/

CVE-2026-42208 w LiteLLM: krytyczne SQL Injection wykorzystane już 36 godzin po ujawnieniu

Cybersecurity news

Wprowadzenie do problemu / definicja

CVE-2026-42208 to krytyczna podatność typu SQL Injection w projekcie LiteLLM, wykorzystywanym jako warstwa pośrednicząca do zarządzania ruchem do modeli językowych, kontrolą dostępu oraz obsługą kluczy API dostawców usług AI. Luka występowała w procesie weryfikacji klucza API po stronie proxy, gdzie niebezpiecznie przetwarzana wartość wejściowa mogła wpływać na zapytania kierowane do bazy danych.

W praktyce oznaczało to możliwość nieautoryzowanego odczytu danych wrażliwych, a w określonych warunkach także ryzyko ich modyfikacji. Szczególnie niepokojące jest to, że atak mógł zostać uruchomiony jeszcze przed poprawnym uwierzytelnieniem użytkownika.

W skrócie

Podatność została publicznie ujawniona w kwietniu 2026 roku i bardzo szybko zaczęła być wykorzystywana w rzeczywistych atakach. Według obserwacji badaczy pierwsze próby nadużyć pojawiły się około 36 godzin po publikacji informacji o luce.

  • dotyczyła wersji LiteLLM od 1.81.16 do 1.83.6,
  • umożliwiała atak bez posiadania poprawnych danych logowania,
  • wykorzystywała spreparowany nagłówek Authorization,
  • prowadziła do enumeracji schematu bazy danych,
  • została załatana w wersji 1.83.7.

Kontekst / historia

LiteLLM jest szeroko wykorzystywany w środowiskach deweloperskich i produkcyjnych jako centralna warstwa integracyjna dla wielu modeli oraz dostawców LLM. Takie rozwiązania upraszczają zarządzanie dostępem, rozliczanie użycia i dystrybucję ruchu, ale jednocześnie koncentrują w jednym miejscu dużą liczbę sekretów, poświadczeń i ustawień środowiskowych.

Przypadek CVE-2026-42208 pokazuje, że infrastruktura AI stała się pełnoprawnym celem ataków. Bramy API dla modeli językowych, proxy i systemy zarządzające kluczami są dziś równie atrakcyjne dla napastników jak klasyczne panele administracyjne, narzędzia CI/CD czy publicznie dostępne interfejsy zarządzania.

Analiza techniczna

Źródłem problemu był sposób budowania zapytania SQL podczas weryfikacji klucza API w module proxy. Zamiast bezpiecznej parametryzacji, wartość dostarczona przez klienta była osadzana bezpośrednio w treści zapytania. To klasyczny wzorzec prowadzący do SQL Injection.

Najistotniejszym elementem scenariusza ataku był charakter pre-auth. Atakujący nie musiał dysponować ważnym tokenem ani prawidłowym kontem. Wystarczyło wysłać odpowiednio spreparowany nagłówek Authorization do jednego z endpointów API, takich jak obsługa żądań czatu, aby uruchomić podatną logikę w ścieżce obsługi błędów i doprowadzić do wykonania niebezpiecznego zapytania.

Zaobserwowane działania nie wyglądały na przypadkowe skanowanie internetu. Badacze wskazali na bardziej ukierunkowaną aktywność skoncentrowaną na rozpoznaniu schematu produkcyjnej bazy LiteLLM. Szczególne zainteresowanie budziły tabele przechowujące wirtualne klucze API, poświadczenia dostawców upstream oraz konfigurację środowiskową proxy. Taki dobór celów sugeruje dobrą znajomość architektury aplikacji i wysoką wartość operacyjną przechowywanych tam danych.

Konsekwencje / ryzyko

Skutki wykorzystania tej luki mogą być poważne zarówno dla bezpieczeństwa danych, jak i ciągłości działania usług AI. W najprostszym scenariuszu napastnik uzyskuje dostęp do informacji przechowywanych w bazie danych proxy, w tym do kluczy API, danych konfiguracyjnych, metadanych użytkowników czy ustawień tenantów.

Ryzyko nie kończy się jednak na odczycie. Jeśli warstwa bazy danych i aplikacja posiadają odpowiednie uprawnienia, możliwa może być również modyfikacja rekordów. To otwiera drogę do podstawienia własnych kluczy, zmiany konfiguracji proxy, manipulacji politykami dostępu oraz przygotowania środowiska pod dalszą eskalację uprawnień lub wtórne nadużycia finansowe związane z wykorzystaniem zewnętrznych usług AI.

Szczególnie niebezpieczne jest to, że podatność dotyka centralnej bramy do usług AI. W takich systemach skupione są sekrety, zależności integracyjne i logika kontroli dostępu. Jeśli komponent tego typu jest wystawiony do sieci publicznej, czas reakcji na podobną lukę powinien być liczony w godzinach, a nie dniach.

Rekomendacje

Podstawowym działaniem jest niezwłoczna aktualizacja LiteLLM do wersji 1.83.7 lub nowszej. Organizacje korzystające z podatnych wydań powinny potraktować ten przypadek jak potencjalny incydent bezpieczeństwa, a nie tylko standardową czynność z obszaru patch management.

  • zidentyfikować wszystkie instancje LiteLLM, także w środowiskach testowych i deweloperskich,
  • potwierdzić używaną wersję oraz zakres publicznej ekspozycji endpointów proxy,
  • przeanalizować logi HTTP i aplikacyjne pod kątem nietypowych nagłówków Authorization, błędów SQL i prób enumeracji schematu,
  • zweryfikować, czy w bazie danych nie pojawiły się nieautoryzowane zmiany w tabelach z kluczami, poświadczeniami i konfiguracją,
  • obrócić wszystkie sekrety przechowywane przez proxy, jeśli istnieje choćby częściowe podejrzenie dostępu do danych,
  • ograniczyć ekspozycję publiczną poprzez segmentację sieci, listy kontroli dostępu i dodatkowe warstwy uwierzytelniania,
  • dodać wskaźniki kompromitacji do systemów monitoringu i detekcji,
  • jeśli natychmiastowa aktualizacja nie jest możliwa, wdrożyć obejście konfiguracyjne polegające na wyłączeniu logów błędów przez ustawienie disable_error_logs: true.

Z perspektywy strategicznej zespoły bezpieczeństwa powinny traktować AI gateway jako systemy wysokiej krytyczności. To już nie tylko warstwa integracyjna, lecz także koncentrator tożsamości, kosztów i sekretów dla całego ekosystemu usług opartych na modelach językowych.

Podsumowanie

CVE-2026-42208 jest wyraźnym sygnałem, że infrastruktura AI znajduje się dziś w centrum zainteresowania atakujących. W LiteLLM pojedynczy błąd SQL Injection w krytycznej ścieżce uwierzytelniania umożliwił ataki bez potrzeby posiadania ważnych poświadczeń, a pierwsze próby wykorzystania wykryto zaledwie 36 godzin po ujawnieniu luki.

Dla organizacji korzystających z bram LLM i proxy API oznacza to konieczność stosowania tych samych standardów bezpieczeństwa, które od dawna obowiązują dla najbardziej wrażliwych elementów infrastruktury produkcyjnej. Szybkie łatanie, monitoring, rotacja sekretów i ograniczanie ekspozycji powinny być tu standardem, a nie reakcją awaryjną.

Źródła

  1. Security Affairs — https://securityaffairs.com/191483/hacking/cve-2026-42208-litellm-bug-exploited-36-hours-after-its-disclosure.html
  2. Sysdig Blog — CVE-2026-42208: Targeted SQL injection against LiteLLM’s authentication path discovered 36 hours following vulnerability disclosure — https://www.sysdig.com/blog/cve-2026-42208-targeted-sql-injection-against-litellms-authentication-path-discovered-36-hours-following-vulnerability-disclosure
  3. Sysdig Newsroom — CVE-2026-42208 coverage reference — https://www.sysdig.com/newsroom/press-releases

Krytyczna podatność LangChain Core umożliwia SSTI i zdalne wykonanie kodu

Cybersecurity news

Wprowadzenie do problemu / definicja

W ekosystemie aplikacji opartych na modelach językowych bezpieczeństwo warstwy pomocniczej, w tym mechanizmów serializacji i deserializacji, ma bezpośredni wpływ na odporność całego środowiska. Opisana podatność w LangChain Core dotyczy niebezpiecznej deserializacji danych wejściowych, która może prowadzić do Server-Side Template Injection (SSTI), a następnie do zdalnego wykonania kodu (RCE).

Problem pojawia się wtedy, gdy dane kontrolowane przez użytkownika są błędnie interpretowane jako zaufane obiekty frameworka. W praktyce umożliwia to odtworzenie niebezpiecznych struktur aplikacyjnych i uruchomienie złośliwej logiki po stronie serwera.

W skrócie

Podatność została opisana jako CVE-2025-68664 i dotyczy wersji LangChain oraz LangChain Core wcześniejszych niż 0.3.81 oraz 1.2.5. Źródłem problemu jest obsługa słownika zawierającego specjalny klucz wykorzystywany przez framework do oznaczania serializowanych obiektów.

  • możliwa jest deserializacja kontrolowanych danych do obiektu PromptTemplate,
  • atak wykorzystuje format jinja2,
  • skutkiem może być SSTI,
  • w dalszej fazie ataku możliwe jest wykonanie poleceń systemowych.

Z perspektywy bezpieczeństwa jest to podatność o bardzo wysokim znaczeniu, szczególnie w środowiskach przetwarzających niezaufane dane, zapisane workflow lub współdzielone obiekty między usługami.

Kontekst / historia

LangChain jest szeroko wykorzystywany do budowy agentów, łańcuchów przetwarzania oraz aplikacji integrujących modele językowe z bazami danych, usługami zewnętrznymi i narzędziami automatyzacji. Wraz ze wzrostem popularności tych rozwiązań rośnie również powierzchnia ataku związana z promptami, parserami, pamięcią konwersacyjną i formatami serializacji.

W tym przypadku problem nie wynika z pojedynczej wady samego silnika szablonów, ale z całego łańcucha zdarzeń: błędnej serializacji, niebezpiecznej deserializacji i późniejszego renderowania treści szablonu. To ważne, ponieważ wiele organizacji koncentruje się na ochronie promptów, pomijając bezpieczeństwo transportu i przechowywania obiektów aplikacyjnych.

Podatność została zaadresowana w poprawionych wydaniach bibliotek. Zagrożenie pozostaje jednak istotne dla organizacji utrzymujących starsze wersje, własne forki kodu oraz integracje korzystające z danych pochodzących z niezweryfikowanych źródeł.

Analiza techniczna

Techniczny rdzeń podatności dotyczy funkcji serializujących i deserializujących obiekty. Framework wykorzystuje specjalną strukturę identyfikującą własne komponenty. Jeżeli aplikacja dopuszcza serializację dowolnych słowników przekazanych przez użytkownika, a następnie odtwarza je jako struktury LangChain, napastnik może przygotować dane wyglądające jak legalna definicja konstruktora.

W scenariuszu ataku złośliwy ładunek wskazuje na konstrukcję PromptTemplate i definiuje szablon w formacie jinja2. Po deserializacji obiekt zostaje utworzony jako prawidłowy komponent frameworka, a jego późniejsze renderowanie prowadzi do interpretacji treści po stronie serwera.

  • napastnik dostarcza kontrolowany słownik z kluczem rozpoznawanym jako znacznik obiektu frameworka,
  • mechanizm serializacji nie neutralizuje tej struktury,
  • funkcja deserializacji traktuje dane jak zaufany obiekt,
  • tworzony jest obiekt szablonu zawierający niebezpieczny payload,
  • renderowanie szablonu prowadzi do SSTI,
  • SSTI może umożliwić wykonanie poleceń systemowych lub dostęp do danych środowiskowych.

Formalnie jest to przypadek niebezpiecznej deserializacji, jednak praktyczny wpływ wynika z przecięcia kilku warstw logiki aplikacyjnej: formatu obiektów, silnika szablonów i uprawnień procesu uruchomieniowego. W środowiskach produkcyjnych skutkiem może być odczyt sekretów, tokenów API, zmiennych środowiskowych oraz danych konfiguracyjnych.

Konsekwencje / ryzyko

Największe ryzyko dotyczy aplikacji AI, które przyjmują zewnętrzne workflow, zapisują i przywracają obiekty LangChain albo renderują prompty pochodzące z niezaufanych źródeł. Szczególnie niebezpieczne są wdrożenia działające z dostępem do wrażliwych sekretów i szerokich zasobów sieciowych.

  • wyciek kluczy API i tokenów usług LLM,
  • ujawnienie poświadczeń chmurowych i danych klientów,
  • dostęp do informacji konfiguracyjnych środowiska,
  • możliwość dalszego ruchu bocznego w infrastrukturze,
  • zwiększone ryzyko nadużyć w architekturach agentowych.

Ryzyko rośnie także wtedy, gdy organizacja zakłada, że serializowane dane mają charakter wyłącznie wewnętrzny. W praktyce mogą one pochodzić z webhooków, kolejek, integracji SaaS, repozytoriów promptów lub paneli administracyjnych dostępnych dla wielu użytkowników.

Rekomendacje

Podstawowym działaniem naprawczym jest aktualizacja do wersji niezawierających podatności. Organizacje powinny sprawdzić, czy w środowisku nie występują wersje wcześniejsze niż 0.3.81 lub 1.2.5, a następnie przeprowadzić przegląd zależności bezpośrednich i pośrednich.

  • zablokować deserializację niezaufanych danych do obiektów frameworka,
  • traktować zewnętrzne słowniki i konfiguracje jako dane, a nie obiekty wykonywalne,
  • ograniczyć użycie formatów szablonów wysokiego ryzyka tam, gdzie nie są niezbędne,
  • przeanalizować wszystkie miejsca tworzenia i renderowania PromptTemplate,
  • odseparować sekrety od procesu aplikacyjnego i stosować poświadczenia krótkotrwałe,
  • uruchamiać aplikacje LLM z minimalnymi uprawnieniami,
  • monitorować nietypowe renderowanie szablonów i proces ładowania obiektów,
  • wdrożyć reguły detekcyjne pod kątem SSTI i nadużyć mechanizmów deserializacji,
  • przeprowadzić przegląd logów związanych z ładowaniem pipeline’ów, promptów i konfiguracji agentów.

W środowiskach korporacyjnych dobrą praktyką będzie również wykonanie Software Composition Analysis, walidacja SBOM oraz wdrożenie polityk blokujących publikację podatnych wersji bibliotek AI do produkcji.

Podsumowanie

CVE-2025-68664 pokazuje, że bezpieczeństwo aplikacji opartych na LLM nie kończy się na filtrowaniu promptów i ochronie modeli. Krytyczne znaczenie mają również pozornie pomocnicze mechanizmy frameworków, takie jak serializacja i deserializacja.

W tym przypadku połączenie błędnej obsługi specjalnego klucza obiektowego z możliwością utworzenia szablonu Jinja2 prowadzi do scenariusza SSTI/RCE o bardzo wysokim wpływie operacyjnym. Dla zespołów bezpieczeństwa, DevSecOps i właścicieli platform AI oznacza to konieczność pilnej aktualizacji bibliotek, przeglądu przepływów danych oraz ograniczenia zaufania do wszystkich zewnętrznych struktur wejściowych.

Źródła

  1. Exploit Database – LangChain Core 1.2.4 – SSTI/RCE – Multiple webapps Exploit
  2. NVD – CVE-2025-68664
  3. GitHub Security Advisory – GHSA-c67j-w6g6-q2cm
  4. LangChain Release Notes – langchain-core 1.2.5
  5. PyPI – langchain-core package

Krytyczna luka SQL Injection w LiteLLM aktywnie wykorzystywana. Zagrożone klucze API i sekrety środowiskowe

Cybersecurity news

Wprowadzenie do problemu / definicja

LiteLLM to popularna warstwa pośrednia i brama API dla dużych modeli językowych, używana do ujednolicania dostępu do wielu dostawców AI. Najnowszy incydent dotyczy krytycznej podatności typu SQL Injection oznaczonej jako CVE-2026-42208, która może być wykorzystana bez uwierzytelnienia podczas weryfikacji klucza API w komponencie proxy.

Problem jest szczególnie poważny, ponieważ dotyczy elementu stojącego często w centrum architektury aplikacji AI. W praktyce taka brama może przechowywać klucze dostępu do usług zewnętrznych, sekrety środowiskowe, konfigurację oraz dane niezbędne do routingu ruchu do modeli.

W skrócie

Podatność CVE-2026-42208 wynika z nieprawidłowego osadzania danych wejściowych w zapytaniu SQL podczas sprawdzania klucza API. Atakujący może przesłać spreparowany nagłówek Authorization do endpointów API i uruchomić podatny kod bez wcześniejszego logowania.

  • Zagrożone są wersje LiteLLM od 1.81.16 do 1.83.6.
  • Poprawka została opublikowana w wersji 1.83.7.
  • Zaobserwowano aktywne próby wykorzystania krótko po publicznym ujawnieniu luki.
  • Możliwy jest odczyt danych z bazy oraz potencjalna ich modyfikacja.

Kontekst / historia

LiteLLM zyskał dużą popularność jako warstwa pośrednia upraszczająca integrację z wieloma modelami za pomocą jednego interfejsu. To sprawia, że rozwiązanie staje się atrakcyjnym celem dla cyberprzestępców, ponieważ kompromitacja jednej instancji może otworzyć drogę do wielu backendów jednocześnie.

W przypadku CVE-2026-42208 problem został opisany jako krytyczna luka w ścieżce weryfikacji klucza API. Poprawka pojawiła się 20 kwietnia 2026 roku, a pierwsze publicznie odnotowane próby wykorzystania wykryto już około 36 godzin później. Taka dynamika potwierdza, że infrastruktura AI jest obecnie monitorowana przez atakujących niemal natychmiast po publikacji informacji o nowych błędach.

Znaczenie incydentu zwiększa szerszy kontekst bezpieczeństwa projektu. W ostatnim czasie wokół LiteLLM pojawiały się również informacje o incydentach związanych z łańcuchem dostaw, co dodatkowo podnosi poziom ryzyka dla organizacji korzystających z tego narzędzia w środowiskach produkcyjnych.

Analiza techniczna

Źródłem podatności jest sposób budowania zapytania do bazy danych podczas weryfikacji klucza API przez proxy. Zamiast bezpiecznego użycia parametryzowanych zapytań, podatny kod miał osadzać dane wejściowe bezpośrednio w treści SQL, co otwiera drogę do klasycznego SQL Injection.

Szczególnie niebezpieczny jest fakt, że luka jest osiągalna bez uwierzytelnienia. Atakujący może wysłać odpowiednio przygotowany nagłówek Authorization: Bearer do jednego z endpointów obsługujących ruch do modeli i uruchomić podatny fragment kodu jeszcze przed poprawną walidacją dostępu.

Z analiz badaczy wynika, że obserwowane działania nie przypominały prostego, masowego skanowania. Kampanie miały charakter bardziej ukierunkowany i skupiały się na tabelach zawierających klucze API, dane konfiguracyjne, poświadczenia dostawców modeli oraz sekrety środowiskowe. W kolejnych etapach ataku zmieniano adresy IP i dopasowywano ładunki do rozpoznanego schematu bazy, co sugeruje iteracyjne doskonalenie exploitu.

Usunięcie błędu polegało na zastąpieniu konkatenacji tekstu parametryzowanymi zapytaniami SQL. Producent wskazał również obejście tymczasowe polegające na ustawieniu disable_error_logs: true w general_settings, jednak należy je traktować jedynie jako środek awaryjny, a nie pełne rozwiązanie problemu.

Konsekwencje / ryzyko

Ryzyko związane z CVE-2026-42208 jest bardzo wysokie, ponieważ łączy zdalny wektor ataku, brak potrzeby logowania, niski poziom złożoności oraz możliwość uzyskania dostępu do danych o wysokiej wartości operacyjnej i finansowej.

Potencjalne skutki kompromitacji instancji LiteLLM obejmują:

  • wyciek kluczy API do usług AI i platform chmurowych,
  • przejęcie kluczy wirtualnych i kluczy nadrzędnych,
  • ujawnienie sekretów środowiskowych oraz konfiguracji aplikacyjnej,
  • możliwość modyfikacji danych w bazie proxy,
  • ryzyko dalszego ruchu bocznego do innych systemów zależnych od przechowywanych poświadczeń.

Dla organizacji wykorzystujących LiteLLM jako centralną bramę do wielu modeli skutki mogą być szczególnie dotkliwe. Jeden skuteczny atak może zapewnić przeciwnikowi dostęp do wielu usług jednocześnie, w tym środowisk produkcyjnych, kont rozliczeniowych oraz integracji chmurowych.

Rekomendacje

Najważniejszym działaniem jest natychmiastowa aktualizacja LiteLLM do wersji 1.83.7 lub nowszej. Organizacje korzystające z wersji od 1.81.16 do 1.83.6 powinny przyjąć, że instancje wystawione do internetu mogły już zostać objęte próbami wykorzystania.

  • zaktualizować wszystkie instancje do bezpiecznej wersji,
  • jeśli aktualizacja nie jest możliwa od razu, wdrożyć obejście z wyłączeniem wskazanej ścieżki logowania błędów,
  • obrócić wszystkie klucze przechowywane w bazie LiteLLM, w tym master keys, virtual keys i poświadczenia dostawców modeli,
  • przeanalizować logi HTTP pod kątem nietypowych nagłówków Authorization i podejrzanych żądań do endpointów LLM,
  • sprawdzić historię połączeń do bazy danych oraz anomalie związane z odczytem wrażliwych tabel,
  • ograniczyć ekspozycję endpointów LiteLLM do zaufanych sieci lub warstwy VPN,
  • wdrożyć reguły WAF i mechanizmy detekcji anomalii dla wzorców charakterystycznych dla SQL Injection,
  • przeprowadzić pełny przegląd tajemnic i integracji zależnych od LiteLLM.

W środowiskach o wysokiej krytyczności uzasadnione jest także wszczęcie standardowego postępowania incydentowego, obejmującego analizę artefaktów, weryfikację integralności systemu, przegląd zmian konfiguracyjnych oraz ocenę ewentualnego wtórnego wykorzystania przechowywanych poświadczeń.

Podsumowanie

CVE-2026-42208 pokazuje, że komponenty pośredniczące w ruchu do modeli AI stały się infrastrukturą wysokiej wartości dla atakujących. W przypadku LiteLLM pre-auth SQL Injection może prowadzić do ujawnienia najbardziej wrażliwych danych przechowywanych przez proxy, a szybkie pojawienie się prób wykorzystania potwierdza, że okno reakcji dla obrońców jest dziś bardzo krótkie.

Dla zespołów bezpieczeństwa oznacza to konieczność priorytetowego patchowania, rotacji sekretów oraz traktowania publicznie dostępnych, podatnych instancji jako potencjalnie naruszonych do czasu przeprowadzenia pełnej weryfikacji.

Źródła

  1. LiteLLM: SQL injection in Proxy API key verification — https://github.com/BerriAI/litellm/security/advisories/GHSA-r75f-5x8p-qvmc
  2. BerriAI/litellm repository — https://github.com/BerriAI/litellm
  3. Hackers are exploiting a critical LiteLLM pre-auth SQLi flaw — https://www.bleepingcomputer.com/news/security/hackers-are-exploiting-a-critical-litellm-pre-auth-sqli-flaw/
  4. Popular LiteLLM PyPI package backdoored to steal credentials, auth tokens — https://www.bleepingcomputer.com/news/security/popular-litellm-pypi-package-compromised-in-teampcp-supply-chain-attack/
  5. Sysdig blog: CVE-2026-42208 targeted SQL injection against LiteLLM — https://www.sysdig.com/blog/cve-2026-42208-targeted-sql-injection-against-litellms-authentication-path-discovered-36-hours-following-vulnerability-disclosure

CVE-2026-33626 w LMDeploy: luka SSRF wykorzystana kilkanaście godzin po ujawnieniu

Cybersecurity news

Wprowadzenie do problemu / definicja

CVE-2026-33626 to podatność typu Server-Side Request Forgery (SSRF) wykryta w projekcie LMDeploy, otwartoźródłowym narzędziu do kompresji, wdrażania i udostępniania dużych modeli językowych oraz modeli vision-language. Problem dotyczył mechanizmu pobierania obrazów, który akceptował zdalne adresy URL bez właściwej walidacji hostów i adresów IP. W praktyce oznaczało to możliwość wymuszenia po stronie serwera połączeń do zasobów wewnętrznych, usług metadanych chmurowych i innych systemów niedostępnych bezpośrednio z Internetu.

W skrócie

Luka została sklasyfikowana jako podatność wysokiego ryzyka z oceną CVSS 7.5 i dotyczyła LMDeploy 0.12.0 oraz starszych wersji, jeśli środowisko miało włączoną obsługę vision-language. Podatny mechanizm znajdował się w funkcji pobierającej obrazy na podstawie pola image_url. Z publicznych analiz wynika, że pierwsze próby wykorzystania odnotowano już około 12 godzin i 31 minut po publikacji ostrzeżenia bezpieczeństwa.

  • podatność umożliwiała skanowanie zasobów wewnętrznych z poziomu serwera modeli,
  • atakujący testowali dostęp do AWS IMDS, Redis, MySQL i lokalnych interfejsów administracyjnych,
  • krótkie okno między ujawnieniem a atakiem pokazuje rosnące zainteresowanie cyberprzestępców infrastrukturą AI.

Kontekst / historia

LMDeploy jest wykorzystywany do serwowania modeli LLM i VLM przez interfejs HTTP zgodny z popularnym wzorcem API dla systemów generatywnej AI. Tego rodzaju komponenty coraz częściej trafiają do środowisk produkcyjnych, gdzie mają łączność z segmentami prywatnymi, usługami pomocniczymi, magazynami danych i mechanizmami autoryzacji w chmurze.

Advisory dotyczące CVE-2026-33626 opublikowano 21 kwietnia 2026 roku. Badacze zwrócili uwagę, że przypadek ten wpisuje się w szerszy trend błyskawicznej operacjonalizacji błędów w infrastrukturze AI. W tym incydencie czas między publicznym ujawnieniem a pierwszą zaobserwowaną próbą ataku był wyjątkowo krótki, co potwierdza, że operatorzy zagrożeń aktywnie monitorują nowe zgłoszenia bezpieczeństwa dotyczące narzędzi AI.

Analiza techniczna

Źródłem problemu był sposób obsługi pola image_url w żądaniach kierowanych do endpointu czatu. Gdy użytkownik przekazywał adres obrazu HTTP lub HTTPS, serwer pobierał wskazany zasób po swojej stronie. W podatnej implementacji zabrakło kilku kluczowych zabezpieczeń.

  • braku walidacji docelowego hosta przed wykonaniem żądania,
  • braku blokady dla zakresów prywatnych i lokalnych, takich jak 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 i 169.254.0.0/16,
  • braku kontroli rozwiązywania DNS oraz powiązania odpowiedzi z bezpiecznym adresem,
  • braku domyślnych ograniczeń ekspozycji usługi i dodatkowych wymogów autoryzacyjnych.

W efekcie atakujący mógł wysłać prawidłowo sformułowane żądanie do API i zmusić serwer LMDeploy do pobrania zasobu z sieci lokalnej lub z usług metadanych instancji chmurowej. Szczególnie niebezpieczny pozostaje dostęp do adresu 169.254.169.254, który w wielu środowiskach chmurowych udostępnia metadane instancji oraz czasowe poświadczenia.

Z publicznie opisanych obserwacji wynika, że atak przebiegał etapami. Najpierw testowano dostęp do AWS IMDS i usług Redis. Następnie sprawdzano możliwość komunikacji wychodzącej przez zewnętrzne kanały DNS lub OOB. W kolejnym kroku prowadzono rozpoznanie interfejsu loopback, aby ustalić, jakie usługi są osiągalne z hosta uruchamiającego silnik inferencyjny.

Konsekwencje / ryzyko

Ryzyko związane z CVE-2026-33626 wykracza daleko poza zwykłe ujawnienie danych. W środowiskach produkcyjnych SSRF w serwerze inferencyjnym może stać się punktem wejścia do dalszej kompromitacji infrastruktury.

  • kradzież poświadczeń chmurowych z usług metadanych,
  • dostęp do wewnętrznych baz danych, cache i paneli administracyjnych,
  • mapowanie topologii sieci oraz wykrywanie otwartych portów,
  • budowanie ścieżki do ruchu bocznego,
  • eskalacja incydentu z poziomu komponentu AI do poziomu całego środowiska aplikacyjnego lub chmurowego.

Podatność jest szczególnie groźna tam, gdzie serwer modeli działa w tej samej sieci co usługi backendowe, ma szerokie uprawnienia IAM lub korzysta z domyślnie otwartego ruchu wychodzącego. Nawet jeśli SSRF nie prowadzi bezpośrednio do wykonania kodu, może dostarczyć napastnikowi danych i wiedzy niezbędnych do kolejnych etapów ataku.

Rekomendacje

Organizacje korzystające z LMDeploy powinny potraktować tę lukę jako wymagającą pilnej reakcji operacyjnej. Ochrona nie powinna ograniczać się wyłącznie do aktualizacji aplikacji, lecz obejmować również warstwę sieciową i kontrolę uprawnień.

  • zidentyfikować wszystkie instancje LMDeploy z aktywną obsługą vision-language,
  • przeprowadzić aktualizację lub wdrożyć obejścia ograniczające pobieranie zewnętrznych URL-i,
  • zablokować dostęp procesu inferencyjnego do adresów lokalnych, link-local, RFC1918 i usług metadanych chmurowych,
  • stosować listy dozwolonych domen lub repozytoriów obrazów zamiast dowolnych adresów URL,
  • wymusić kontrolę egress na poziomie hosta, kontenera, klastra i VPC,
  • odseparować serwery inferencyjne od baz danych, cache i interfejsów administracyjnych,
  • włączyć uwierzytelnianie do API oraz ograniczyć nasłuch wyłącznie do niezbędnych interfejsów,
  • monitorować nietypowe połączenia wychodzące, zwłaszcza do adresów lokalnych i usług metadanych,
  • przejrzeć logi pod kątem nietypowych wartości image_url, prób skanowania portów i wywołań OOB,
  • rozważyć rotację poświadczeń chmurowych, jeśli istnieje podejrzenie kontaktu z usługą metadanych.

Podsumowanie

CVE-2026-33626 pokazuje, że podatności SSRF w infrastrukturze AI mogą być wykorzystywane niemal natychmiast po publicznym ujawnieniu. W przypadku LMDeploy problem dotyczył z pozoru prostego mechanizmu pobierania obrazów, ale skutki obejmowały dostęp do zasobów wewnętrznych, usług metadanych i możliwość prowadzenia rozpoznania sieci z poziomu serwera modeli. Dla zespołów bezpieczeństwa to wyraźny sygnał, że komponenty LLM i VLM należy traktować jak krytyczne elementy powierzchni ataku.

Źródła

10 aktywnych technik pośredniego prompt injection zagraża agentom AI

Cybersecurity news

Wprowadzenie do problemu / definicja

Pośredni prompt injection to klasa ataków na systemy sztucznej inteligencji, w której złośliwe instrukcje nie są przekazywane modelowi bezpośrednio przez użytkownika, lecz ukrywane w zewnętrznych źródłach danych. Mogą to być strony internetowe, dokumenty, wiadomości e-mail, bazy wiedzy czy repozytoria treści, które agent AI pobiera i analizuje w toku wykonywania zadania.

Problem pojawia się wtedy, gdy model lub aplikacja nie potrafią jednoznacznie oddzielić danych od instrukcji. W efekcie agent może uznać fragment obcej treści za wiążące polecenie operacyjne, co prowadzi do zmiany logiki działania, obejścia zabezpieczeń lub wykonania nieautoryzowanych akcji.

W skrócie

Badacze zidentyfikowali 10 rzeczywistych przypadków pośredniego prompt injection wykorzystywanych przeciwko agentom AI. To ważny sygnał dla rynku, ponieważ pokazuje, że zagrożenie nie jest już wyłącznie koncepcją badawczą, ale praktycznym wektorem ataku obserwowanym w realnych treściach dostępnych dla systemów LLM.

  • Ataki były osadzane w treściach zewnętrznych dostępnych dla agentów AI.
  • Celem było przejęcie kontroli nad logiką działania modelu lub narzędzi.
  • Skutki mogły obejmować wyciek danych, kradzież kluczy API, manipulację odpowiedziami i nieautoryzowane działania.
  • Najbardziej narażone są systemy RAG i agenci z dostępem do narzędzi wykonawczych.

Kontekst / historia

Prompt injection od dawna znajduje się w centrum zainteresowania środowiska bezpieczeństwa AI, jednak początkowo uwaga skupiała się głównie na atakach bezpośrednich. W takim modelu użytkownik jawnie próbuje skłonić system do złamania reguł działania, ominięcia polityk lub ujawnienia informacji.

Sytuacja zmieniła się wraz z upowszechnieniem architektur RAG, agentów AI oraz integracji z pocztą, przeglądarkami, repozytoriami kodu i systemami biznesowymi. Modele coraz częściej operują na nieufnych danych pochodzących z otoczenia, a to znacząco zwiększa powierzchnię ataku. W takim środowisku zagrożeniem staje się nie tylko użytkownik, ale również każdy dokument lub zasób, który może zostać pobrany do kontekstu modelu.

Najnowsze ustalenia pokazują, że atakujący potrafią projektować treści tak, aby zostały skutecznie odnalezione przez mechanizmy wyszukiwania i retrievalu, a następnie wykonane przez model jako część procesu decyzyjnego. To przesuwa problem z poziomu filtrowania promptów wejściowych na poziom całego łańcucha przetwarzania informacji.

Analiza techniczna

Techniczny fundament pośredniego prompt injection wynika z braku ścisłej granicy między danymi a instrukcjami. Jeśli aplikacja przekazuje modelowi treści pobrane z Internetu, dokumentów lub systemów wewnętrznych, model może potraktować zawarte tam komendy jako istotne wskazówki operacyjne.

Badania wskazują, że złośliwe ładunki są konstruowane w sposób zwiększający ich szansę na pobranie przez mechanizmy retrievalu. W praktyce mogą składać się z fragmentu wyzwalającego, który podnosi prawdopodobieństwo odnalezienia dokumentu, oraz z części właściwej, zawierającej instrukcję atakującą. Taka konstrukcja sprawia, że niebezpieczna treść może trafić do kontekstu modelu nawet przy pozornie neutralnym zapytaniu użytkownika.

Skuteczność ataku zależy od kilku czynników technicznych:

  • sposobu indeksowania i wyszukiwania treści,
  • jakości wyszukiwania semantycznego,
  • reguł łączenia kontekstu przez aplikację,
  • hierarchii instrukcji systemowych i użytkownika,
  • zakresu uprawnień przypisanych agentowi.

Jeśli agent może korzystać z poczty, API, plików, sekretów aplikacyjnych lub systemów administracyjnych, pojedyncza skuteczna iniekcja może przełożyć się na pełnoprawny incydent bezpieczeństwa. Dodatkowym problemem pozostaje wysoki poziom fałszywych alarmów, ponieważ wiele wzorców przypominających prompt injection występuje również w materiałach edukacyjnych i badawczych. To sprawia, że skuteczna detekcja wymaga łączenia sygnatur, analizy semantycznej i ręcznej walidacji.

Konsekwencje / ryzyko

Najpoważniejsze ryzyko polega na tym, że napastnik nie musi mieć bezpośredniego dostępu do interfejsu aplikacji. Wystarczy, że agent AI pobierze wcześniej przygotowaną treść i przetworzy ją jako część kontekstu. Taki scenariusz może prowadzić do ujawnienia danych, historii rozmów, tokenów dostępowych, kluczy API i innych informacji wrażliwych.

W środowiskach firmowych skutki mogą być jeszcze poważniejsze. Agent zintegrowany z systemami biznesowymi może zostać zmanipulowany do wysyłki wiadomości, modyfikacji plików, przekazywania informacji osobom nieuprawnionym, generowania fałszywych rekomendacji lub zakłócania procesów operacyjnych. Szczególnie wysokie ryzyko dotyczy platform, które łączą model z pamięcią długoterminową, narzędziami wykonawczymi i nieufnymi źródłami danych.

  • Wycieki sekretów i danych poufnych
  • Manipulacja odpowiedziami i analizami modelu
  • Przejęcie logiki wykonywania zadań
  • Nieautoryzowane operacje w systemach zewnętrznych
  • Wpływ na decyzje biznesowe i operacyjne

Rekomendacje

Organizacje wdrażające agentów AI powinny przyjąć, że pośredni prompt injection jest realnym i trwałym elementem krajobrazu zagrożeń. Obrona nie może opierać się na pojedynczym filtrze, lecz powinna wykorzystywać podejście defense-in-depth.

Kluczowe znaczenie ma rozdzielanie zaufanych instrukcji systemowych od nieufnych danych pobieranych z zewnątrz. Treści z Internetu, poczty, dokumentów i repozytoriów powinny być wyraźnie oznaczane oraz izolowane, tak aby nie wpływały bezpośrednio na planowanie działań modelu.

Równie istotna jest zasada najmniejszych uprawnień. Agent powinien mieć tylko taki dostęp do narzędzi, danych i sekretów, jaki jest absolutnie niezbędny do wykonania konkretnego zadania. Operacje wysokiego ryzyka, takie jak eksport danych, wysyłka wiadomości, transakcje czy działania administracyjne, powinny wymagać dodatkowego zatwierdzenia przez człowieka.

  • Izolowanie nieufnych danych od warstwy instrukcyjnej
  • Ograniczanie uprawnień agentów i konektorów
  • Wymuszanie potwierdzeń dla działań wysokiego ryzyka
  • Monitorowanie anomalii i odchyleń w zachowaniu agenta
  • Testowanie odporności poprzez red teaming i symulacje ataków
  • Stosowanie piaskownic wykonawczych i kontroli przepływu informacji

Podsumowanie

Wykrycie 10 aktywnych technik pośredniego prompt injection pokazuje, że ataki na agentów AI wkroczyły w fazę praktycznego zastosowania. To już nie tylko zagadnienie akademickie, ale realny problem bezpieczeństwa dla organizacji wdrażających systemy LLM z dostępem do zewnętrznych źródeł danych i narzędzi wykonawczych.

Wraz ze wzrostem autonomii agentów rośnie znaczenie ochrony przed manipulacją kontekstem. Firmy powinny traktować pośredni prompt injection jako jeden z kluczowych wektorów ataku nowej generacji i odpowiednio projektować architekturę bezpieczeństwa swoich aplikacji AI.

Źródła

  1. Researchers Uncover 10 In-the-Wild Prompt Injection Payloads Targeting AI Agents — https://www.infosecurity-magazine.com/news/researchers-10-wild-indirect/
  2. Overcoming the Retrieval Barrier: Indirect Prompt Injection in the Wild for LLM Systems — https://arxiv.org/abs/2601.07072
  3. Defend against indirect prompt injection attacks — https://learn.microsoft.com/en-us/security/zero-trstricted”>https://learn.microsoft.com/en-us/security/zero-trust/sfi/defend-indirect-prompt-injection
  4. Understanding prompt injections — https://openai.com/safety/prompt-injections/
  5. AI threats in the wild: The current state of prompt injections on the web — https://security.googleblog.com/2026/04/ai-threats-in-wild-current-state-of.html