Co znajdziesz w tym artykule?
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.