Tag: LLM

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

Wprowadzenie do problemu / definicja

Mechanizmy pamięci w agentach AI mają zwiększać skuteczność modeli językowych poprzez przechowywanie preferencji użytkownika, kontekstu pracy i informacji potrzebnych w kolejnych sesjach. To jednak tworzy nową powierzchnię ataku. Jeśli napastnik zmodyfikuje plik pamięci lub inne dane kontekstowe, agent może wykonywać szkodliwe instrukcje nie tylko jednorazowo, ale również w sposób trwały, wpływając na przyszłe działania systemu.

W praktyce oznacza to przejście od incydentów sesyjnych do trwałej kompromitacji stanu operacyjnego agenta. Problem nie dotyczy wyłącznie jednego narzędzia, lecz całej klasy rozwiązań wykorzystujących pamięć długoterminową, warstwy orkiestracji i integracje z zewnętrznymi źródłami danych.

W skrócie

Zatrucie pamięci agentów AI polega na wprowadzeniu złośliwych instrukcji do plików lub artefaktów, które później są ponownie ładowane do kontekstu modelu. W efekcie agent może przez długi czas podejmować decyzje zgodne z intencją napastnika, mimo że sam model bazowy pozostaje bezstanowy.

• atak może utrzymywać się między sesjami i projektami,
• złośliwe instrukcje mogą wpływać na generowany kod i decyzje operacyjne,
• ryzyko obejmuje wybór niebezpiecznych pakietów, osłabienie konfiguracji i propagację błędów,
• zagrożenie dotyczy pamięci, plików tekstowych, konfiguracji oraz danych kontekstowych używanych przez agentów AI.

Kontekst / historia

W ostatnim czasie bezpieczeństwo agentów AI stało się jednym z kluczowych tematów w obszarze AppSec i ochrony łańcucha dostaw oprogramowania. Wraz z popularyzacją asystentów kodowania i narzędzi opartych na LLM pojawiły się nowe klasy zagrożeń, takie jak prompt injection, zatrucie kontekstu, manipulacja pamięcią długoterminową i nadużycia integracji z usługami zewnętrznymi.

Badania opisujące kompromitację plików pamięci wykorzystywanych przez asystentów AI pokazały, że atak nie musi kończyć się na pojedynczym wywołaniu modelu. Po zapisaniu złośliwej treści do pamięci system może odtwarzać ją w kolejnych sesjach, projektach lub interakcjach użytkownika. To znacząco zwiększa trwałość ataku i utrudnia jego wykrycie.

Analiza techniczna

Modele bazowe są z natury bezstanowe, dlatego ciągłość działania agentów wymaga dostarczania im stanu z dodatkowych warstw, takich jak pliki pamięci, bazy wektorowe, systemy RAG, adaptery czy konfiguracje projektowe. Każdy z tych elementów może stać się nośnikiem nieautoryzowanych instrukcji.

W analizowanych scenariuszach wektorem wejścia były między innymi mechanizmy post-install hook w ekosystemie pakietów, które pozwalały modyfikować pliki pamięci używane przez narzędzia AI. Jeśli taka zawartość trafia następnie do system promptu lub uprzywilejowanego kontekstu, model może potraktować złośliwy tekst jako zaufaną instrukcję operacyjną.

To podejście jest groźne, ponieważ szkodliwy komponent nie musi mieć postaci klasycznego kodu wykonywalnego. Wystarczy odpowiednio sformułowany tekst, który warstwa orkiestracji zinterpretuje jako część stanu systemu. Podatne mogą być więc nie tylko dedykowane pliki pamięci, ale także pliki Markdown, zależności, dokumentacja projektowa czy reguły pracy modelu.

Z perspektywy architektury bezpieczeństwa jest to rozszerzenie znanego problemu prompt injection. Różnica polega na trwałości oraz na tym, że zainfekowany kanał może być traktowany przez system jako zaufany. W rezultacie memory poisoning staje się formą trwałego skażenia środowiska roboczego agenta, a nie jedynie jednorazową manipulacją odpowiedzią.

Konsekwencje / ryzyko

Największym zagrożeniem jest utrata integralności działań agenta AI. Organizacja może przez długi czas nie zauważyć, że model podejmuje decyzje zgodne z logiką zaszytą przez napastnika, a nie z polityką bezpieczeństwa firmy.

W środowiskach deweloperskich skutki mogą być szczególnie dotkliwe, ponieważ agenci często mają dostęp do kodu, repozytoriów, konfiguracji CI/CD, zależności i pośrednio do danych wrażliwych. Zatruta pamięć może prowadzić do wdrażania ryzykownych bibliotek, osłabienia konfiguracji bezpieczeństwa, wprowadzania poufnych danych do kodu lub dokumentacji oraz propagacji niepoprawnych zmian na inne zespoły.

Problemem pozostaje także niska widoczność incydentu. Złośliwe instrukcje mogą wyglądać jak zwykła zawartość tekstowa w pozornie nieszkodliwym pliku. Im dłużej pamięć jest przechowywana i rzadziej weryfikowana, tym większa szansa, że atak pozostanie aktywny przez wiele dni lub tygodni.

Rekomendacje

Organizacje wdrażające agentów AI powinny traktować pliki pamięci, dane kontekstowe i artefakty sterujące jako zasoby wysokiego ryzyka. Wymagają one podobnych kontroli jak konfiguracje bezpieczeństwa, skrypty startowe czy komponenty łańcucha dostaw.

• wdrożenie kontroli integralności plików pamięci i ich wersjonowania,
• regularne przeglądy bezpieczeństwa oraz monitoring zmian w artefaktach kontekstowych,
• skanowanie zależności, hooków instalacyjnych i konfiguracji pod kątem nieautoryzowanych modyfikacji,
• ograniczenie retencji pamięci i okresowe czyszczenie stanu długoterminowego,
• odbudowa pamięci wyłącznie z zaufanych źródeł po wykryciu anomalii,
• separacja uprawnień i ograniczenie dostępu agenta do systemów wysokiego ryzyka,
• wymaganie zatwierdzenia człowieka dla działań o wysokim wpływie operacyjnym.

W praktyce zespoły bezpieczeństwa powinny przyjąć, że każdy plik tekstowy dołączany do kontekstu modelu może stać się wektorem ataku. Ochrona agentów AI nie może więc ograniczać się do samego modelu, lecz musi obejmować także stan, pamięć i warstwę orkiestracji.

Podsumowanie

Zatrucie pamięci agentów AI to jedno z najpoważniejszych i nadal niedoszacowanych zagrożeń w bezpieczeństwie systemów opartych na LLM. Mechanizmy, które mają poprawiać użyteczność i personalizację, jednocześnie tworzą trwały kanał wpływu na zachowanie modelu.

Dla organizacji oznacza to konieczność rozszerzenia klasycznego podejścia do AppSec i supply chain security o nowe klasy artefaktów: pliki pamięci, dane kontekstowe oraz logikę orkiestracji agentów. W najbliższych latach to właśnie ochrona stanu operacyjnego agentów może stać się jednym z kluczowych warunków bezpiecznego wdrażania AI w środowiskach produkcyjnych.

Źródła

1. Bad Memories Still Haunt AI Agents — https://www.darkreading.com/vulnerabilities-threats/bad-memories-haunt-ai-agents
2. Cisco: Weaponizing AI Assistant Memories: Prompt Injection & Persistence in Anthropic Claude Code — https://blogs.cisco.com/security/weaponizing-ai-assistant-memories-prompt-injection-persistence-in-anthropic-claude-code
3. Palo Alto Networks Unit 42: Context Manipulation Attacks in AI Agents — https://unit42.paloaltonetworks.com/context-manipulation-attacks-ai-agents/
4. Princeton University / Sentient AI: Emergent Misalignment from Memory Poisoning — https://arxiv.org/abs/2502.17424
5. Open Worldwide Application Security Project: OWASP Top 10 for LLM Applications — https://owasp.org/www-project-top-10-for-large-language-model-applications/

Wprowadzenie do problemu / definicja

W ekosystemie narzędzi do serwowania modeli językowych coraz większe znaczenie ma bezpieczeństwo łańcucha dostaw modeli AI. Krytyczna podatność CVE-2026-5760 w projekcie SGLang pokazuje, że model może być nie tylko nośnikiem danych, ale również aktywnym wektorem ataku prowadzącym do zdalnego wykonania kodu na serwerze inferencyjnym.

Problem dotyczy obsługi spreparowanych plików GGUF zawierających złośliwy wpis tokenizer.chat_template. W określonych warunkach taki artefakt może doprowadzić do wykonania dowolnego kodu Pythona w kontekście procesu SGLang.

W skrócie

• CVE-2026-5760 otrzymała krytyczną ocenę CVSS 9.8.
• Luka dotyczy frameworka SGLang używanego do uruchamiania modeli LLM i modeli multimodalnych.
• Wektor ataku obejmuje endpoint /v1/rerank oraz złośliwie przygotowany plik GGUF.
• Źródłem problemu jest renderowanie szablonów Jinja2 bez odpowiedniego sandboxingu.
• Skutkiem może być zdalne wykonanie kodu, kradzież sekretów i przejęcie serwera inferencyjnego.

Kontekst / historia

SGLang zyskał popularność jako wydajny framework open source do obsługi nowoczesnych obciążeń AI. Wraz ze wzrostem skali wdrożeń rośnie jednak powierzchnia ataku związana z importem modeli, tokenizerów oraz szablonów promptów pochodzących z zewnętrznych repozytoriów.

CVE-2026-5760 wpisuje się w szerszą klasę błędów wynikających z traktowania artefaktów modeli jako pasywnych i zaufanych danych. W praktyce metadane modelu, szablony czatu i inne elementy konfiguracyjne mogą zostać wykorzystane do uruchomienia niepożądanej logiki, jeśli aplikacja interpretuje je bez odpowiednich zabezpieczeń.

To ważna zmiana perspektywy dla zespołów bezpieczeństwa: ryzyko nie ogranicza się już wyłącznie do bibliotek, kontenerów czy zależności, ale obejmuje także same modele AI i ich osadzone metadane.

Analiza techniczna

Istota podatności sprowadza się do użycia środowiska Jinja2 bez izolacji podczas renderowania szablonu czatu. Atakujący może przygotować plik GGUF zawierający złośliwy parametr tokenizer.chat_template, w którym osadza ładunek typu server-side template injection.

Po załadowaniu takiego modelu do SGLang i wywołaniu endpointu /v1/rerank aplikacja odczytuje szablon i renderuje go w kontekście procesu serwera. Jeśli warunki wykonania zostaną spełnione, złośliwy szablon może uruchomić arbitralny kod Pythona, co prowadzi do pełnego zdalnego wykonania kodu na hoście inferencyjnym.

Technicznie problem wynika z połączenia dwóch niebezpiecznych założeń. Po pierwsze, metadane modelu zostały potraktowane jako zaufana konfiguracja. Po drugie, silnik szablonów został wykorzystany w sposób umożliwiający wykonanie niekontrolowanych instrukcji. Taki scenariusz jest szczególnie groźny tam, gdzie serwer AI ma dostęp do kluczy API, systemu plików, sieci wewnętrznej lub innych usług produkcyjnych.

Atak nie musi być dostarczony klasycznym exploitem w pojedynczym żądaniu HTTP. Ładunek może zostać wniesiony wcześniej wraz z modelem, a aktywacja następuje dopiero podczas obsługi konkretnego workflow. To utrudnia detekcję i zwiększa ryzyko przeoczenia kompromitującego artefaktu.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem podatności jest zdalne wykonanie kodu w kontekście usługi SGLang. W praktyce może to oznaczać przejęcie serwera inferencyjnego, wyciek sekretów środowiskowych, modyfikację modeli, instalację mechanizmów trwałego dostępu oraz dalsze przemieszczanie się napastnika po infrastrukturze.

Szczególnie wysokie ryzyko występuje w organizacjach, które:

• korzystają z publicznych lub społecznościowych repozytoriów modeli,
• wdrażają modele bez walidacji metadanych i procesu zatwierdzania,
• udostępniają endpointy rerankingu w środowiskach produkcyjnych,
• uruchamiają inferencję z szerokimi uprawnieniami systemowymi,
• integrują serwery modeli z bazami wiedzy, pipeline’ami CI/CD lub danymi wrażliwymi.

Z perspektywy bezpieczeństwa jest to problem z obszaru AI supply chain. Zamiast kompromitować bibliotekę lub obraz kontenera, napastnik może dostarczyć złośliwy artefakt modelu, który zostanie uznany za legalny zasób operacyjny.

Rekomendacje

Organizacje korzystające z SGLang powinny jak najszybciej zidentyfikować wszystkie instancje obsługujące endpoint /v1/rerank i ładujące modele GGUF z zewnętrznych źródeł. Każdy niezweryfikowany model należy traktować jako potencjalnie złośliwy.

• zrezygnować z renderowania szablonów w niesandboxowanym środowisku Jinja2,
• wdrożyć bezpieczny mechanizm izolacji szablonów,
• ograniczyć lub całkowicie zablokować ładowanie modeli z niezaufanych źródeł,
• traktować pliki GGUF i metadane tokenizerów jako nieufne wejście,
• wdrożyć formalny proces zatwierdzania modeli z kontrolą pochodzenia i skanowaniem metadanych,
• uruchamiać serwery inferencyjne z minimalnymi uprawnieniami,
• segmentować sieciowo infrastrukturę AI i ograniczyć ruch wychodzący,
• monitorować nietypowe procesy, operacje na plikach i połączenia sieciowe z instancji SGLang,
• przeprowadzić przegląd logów pod kątem anomalii po załadowaniu nowych modeli.

W środowiskach o podwyższonym profilu ryzyka warto dodatkowo stosować izolację kontenerową, polityki seccomp lub AppArmor, rozwiązania EDR na hostach GPU oraz kontrolę integralności artefaktów modeli. Jeżeli pochodzenie już wdrożonych modeli budzi wątpliwości, należy rozważyć ich ponowną walidację oraz rotację sekretów dostępnych dla usługi.

Podsumowanie

CVE-2026-5760 pokazuje, że bezpieczeństwo platform AI nie kończy się na API i bibliotece inferencyjnej. Równie istotne są metadane modeli, tokenizerów i szablonów promptów, które mogą stać się pełnoprawnym wektorem ataku prowadzącym do zdalnego wykonania kodu.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że modele AI należy traktować jak potencjalnie niebezpieczne artefakty software’owe. Bez kontroli pochodzenia, walidacji zawartości i ścisłej izolacji runtime łańcuch dostaw AI może stać się jednym z najłatwiejszych punktów wejścia do infrastruktury.

Źródła

1. The Hacker News — SGLang CVE-2026-5760 (CVSS 9.8) Enables RCE via Malicious GGUF Model Files — https://thehackernews.com/2026/04/sglang-cve-2026-5760-cvss-98-enables.html
2. CVE Program — CVE-2026-5760 — https://www.cve.org/CVERecord?id=CVE-2026-5760
3. GitHub — sgl-project/sglang Security Advisories — https://github.com/sgl-project/sglang/security/advisories