Krytyczna podatność w LangChain (CVE-2025-68664): Jak atak wstrzykiwania serializacji zagraża aplikacjom AI

Krytyczna podatność w LangChain (CVE-2025-68664): Jak atak wstrzykiwania serializacji zagraża aplikacjom AI

W świecie, w którym sztuczna inteligencja rewolucjonizuje kolejne branże, bezpieczeństwo fundamentów, na których budowane są te innowacje, staje się absolutnym priorytetem. Niedawne odkrycie rzuca światło na nową klasę zagrożeń na styku AI i klasycznego cyberbezpieczeństwa. Mowa o krytycznej podatności w LangChain, zidentyfikowanej jako CVE-2025-68664, która wstrząsnęła społecznością deweloperów AI. Zagraża ona tysiącom aplikacji na całym świecie, umożliwiając kradzież danych uwierzytelniających, a nawet zdalne wykonanie kodu.

Dla liderów biznesu, CISO i menedżerów IT w Polsce, zrozumienie natury tego zagrożenia jest kluczowe. To nie jest kolejny teoretyczny problem – to realne ryzyko, które może podważyć bezpieczeństwo całych systemów opartych na modelach językowych (LLM). W tym artykule przeprowadzimy dogłębną analizę tej podatności, wyjaśnimy jej mechanizm, wskażemy potencjalne konsekwencje i przedstawimy konkretne kroki, które należy podjąć, aby chronić swoją organizację.

Czym jest LangChain i dlaczego ta podatność ma tak ogromne znaczenie?

LangChain to jeden z najpopularniejszych na świecie frameworków open-source, służący do tworzenia aplikacji wykorzystujących duże modele językowe (LLM). Jak podaje portal The Hacker News, stał się on de facto standardem w branży, ułatwiając deweloperom budowanie złożonych systemów, takich jak chatboty, autonomiczni agenci czy zaawansowane narzędzia do analizy danych. Jego podstawowy pakiet, langchain-core, stanowi fundament, na którym opiera się cały ekosystem.

Popularność LangChain jest oszałamiająca. Według danych z serwisu pepy.tech, pakiet langchain-core został pobrany łącznie około 847 milionów razy, a w ostatnim miesiącu odnotowano blisko 98 milionów pobrań szerszego ekosystemu LangChain. Te liczby pokazują, jak głęboko technologia ta zakorzeniła się w produkcyjnych systemach firm na całym świecie – od startupów po korporacje z listy Fortune 500. To właśnie ta wszechobecność sprawia, że krytyczna podatność w LangChain stanowi tak poważne, systemowe zagrożenie dla globalnego bezpieczeństwa aplikacji AI.

Analiza techniczna: Podatność wstrzykiwania serializacji (CVE-2025-68664)

Podatność, nazwana nieoficjalnie “LangGrinch” i odkryta przez badacza Yarden Porat z Cyata AI, otrzymała ocenę 9.3/10 w skali CVSS, co klasyfikuje ją jako krytyczną. Jej sedno leży w procesie zwanym serializacją – czyli konwersją obiektów programistycznych (np. danych konfiguracyjnych, historii konwersacji) do formatu, który można łatwo przechowywać lub przesyłać.

Błąd w obsłudze klucza ‘lc’

Jak szczegółowo opisano w analizie serwisu Upwind, LangChain używa wewnętrznego mechanizmu, w którym specjalny klucz 'lc' w słowniku Pythona sygnalizuje, że dany obiekt jest wewnętrzną, zaufaną strukturą LangChain, a nie zwykłymi danymi użytkownika. Problem polegał na tym, że funkcje serializujące (dumps() i dumpd()) w podatnych wersjach nie przetwarzały poprawnie danych wejściowych pochodzących z niezaufanych źródeł, takich jak odpowiedzi z modelu LLM.

Jeśli atakujący, poprzez sprytnie skonstruowane zapytanie (tzw. prompt injection), był w stanie zmusić model LLM do wygenerowania odpowiedzi zawierającej słownik z kluczem 'lc', system serializacji traktował go jako zaufany obiekt LangChain. Gdy takie dane były później deserializowane (czyli odczytywane z powrotem do formy obiektu), system interpretował je nie jako tekst, ale jako instrukcję do wykonania. To klasyczny przykład ataku typu wstrzykiwanie serializacji (Deserialization of Untrusted Data, CWE-502), ale osadzony w nowym, unikalnym kontekście aplikacji AI.

Atak ten jest szczególnie podstępny, ponieważ wykorzystuje dane, które deweloperzy mogli uważać za bezpieczne – w końcu pochodzą one z “własnego” modelu AI. Jednak, jak pokazało to odkrycie, dane wyjściowe LLM muszą być traktowane jako w pełni niezaufane źródło danych wejściowych.

Wektory Ataku: Od Prompt Injection po Zatrute Zbiory Danych

Badacze z Cyata AI zidentyfikowali aż dwanaście różnych ścieżek, którymi atakujący mógłby wykorzystać tę podatność. Pokazuje to, jak głęboko problem był zakorzeniony w architekturze frameworka. Do najgroźniejszych wektorów ataku należą:

1. Strumieniowanie zdarzeń (astream_events): W starszej wersji (v1) tej funkcji, dane o zdarzeniach w aplikacji były serializowane w podatny sposób. Atakujący mógł wstrzyknąć złośliwy ładunek do odpowiedzi LLM, który aktywowałby się po stronie klienta odbierającego strumień.
2. Logowanie wykonania (astream_log): Podobnie jak w przypadku strumieniowania, logi operacji były serializowane. Zapisany log, zawierający spreparowaną odpowiedź LLM, stawał się “bombą zegarową”, która mogła eksplodować podczas późniejszej analizy lub odtwarzania logów.
3. Historia konwersacji (RunnableWithMessageHistory): Aplikacje przechowujące historię rozmów z użytkownikiem serializowały ją między kolejnymi interakcjami. Złośliwa odpowiedź LLM mogła zatruć stan konwersacji, prowadząc do eskalacji uprawnień w kolejnych krokach.
4. Mechanizmy cache’owania: Systemy AI często przechowują w pamięci podręcznej kosztowne odpowiedzi modeli. Jeśli zatruta odpowiedź została zapisana w cache’u, mogła być wielokrotnie odczytywana i wykorzystywana do atakowania różnych użytkowników lub systemów.
5. Wektoryzacja i bazy danych (InMemoryVectorStore.load): Atakujący, który mógł wpłynąć na dokumenty trafiające do bazy wektorowej (np. poprzez zatrucie danych treningowych), mógł umieścić w metadanych dokumentu złośliwy ładunek, który aktywowałby się podczas operacji wyszukiwania.

Jak podkreśla The Hacker News, najbardziej prawdopodobnym i niebezpiecznym scenariuszem w praktyce jest atak poprzez prompt injection. Atakujący nie potrzebuje bezpośredniego dostępu do systemu. Wystarczy, że poprzez publicznie dostępne API (np. chatbota) wyśle spreparowane zapytanie, które skłoni model LLM do umieszczenia złośliwej struktury z kluczem 'lc' w polach metadanych odpowiedzi (np. additional_kwargs). Aplikacja, ufając tym metadanym, serializuje je, a podatność zostaje aktywowana w dalszej części procesu.

Skala Zagrożenia i Zakres Podatności

Zasięg problemu jest ogromny i dotyczy zarówno ekosystemu Pythona, jak i JavaScript.

Wersje podatne (Python – langchain-core):

• Wszystkie wersje od 1.0.0 do 1.2.4 (włącznie). Poprawka znajduje się w wersji 1.2.5 i nowszych.
• Wszystkie wersje starszej linii przed 0.3.81. Poprawka znajduje się w wersji 0.3.81 i nowszych.

Równoległa podatność w JavaScript (CVE-2025-68665):

• @langchain/core: Wersje od 1.0.0 do 1.1.7 (poprawione w 1.1.8) oraz wersje przed 0.3.80 (poprawione w 0.3.80).
• langchain: Wersje od 1.0.0 do 1.2.2 (poprawione w 1.2.3) oraz wersje przed 0.3.37 (poprawione w 0.3.37).

Fakt istnienia podatności w obu głównych językach programowania oznacza, że firmy korzystające z rozwiązań full-stack, gdzie backend w Pythonie komunikuje się z frontendem w JavaScripcie, są podwójnie narażone. Skuteczne zarządzanie podatnościami wymaga w tym przypadku skoordynowanego działania na obu platformach.

Konsekwencje dla Biznesu: Co Może Osiągnąć Atakujący?

Skutki udanego ataku mogą być katastrofalne. Badacze wykazali trzy główne kategorie możliwych do osiągnięcia celów:

1. Kradzież Danych Wrażliwych i Kluczy API

Najprostszym do wykonania atakiem jest ekstrakcja zmiennych środowiskowych z serwera, na którym działa aplikacja. W starszych wersjach LangChain, funkcja deserializacji domyślnie próbowała odczytywać sekrety ze zmiennych środowiskowych. Atakujący mógł spreparować ładunek, który po deserializacji odczytywał wartość np. AWS_SECRET_ACCESS_KEY czy DATABASE_URL i zwracał ją w odpowiedzi. W świecie chmury, gdzie klucze API i dane uwierzytelniające są często przechowywane w ten sposób, oznacza to natychmiastową kompromitację krytycznej infrastruktury.

2. Ataki na Infrastrukturę Wewnętrzną (SSRF)

Podatność umożliwiała atakującemu tworzenie instancji niektórych wewnętrznych klas LangChain z kontrolowanymi przez siebie parametrami. Jak wskazali badacze, jedną z takich klas była ChatBedrockConverse z pakietu langchain_aws. Jej konstruktor (__init__) wykonywał żądanie sieciowe do określonego adresu URL. Atakujący mógł stworzyć obiekt tej klasy, podając jako adres URL zasób w sieci wewnętrznej firmy. Jest to klasyczny atak Server-Side Request Forgery (SSRF), pozwalający na skanowanie sieci wewnętrznej i atakowanie innych systemów z perspektywy zaufanego serwera aplikacji.

3. Zdalne Wykonanie Kodu (RCE) – Najgorszy Scenariusz

Najpoważniejszym zagrożeniem jest potencjalne zdalne wykonanie kodu. Wśród klas, które można było tworzyć, znajdowała się PromptTemplate, obsługująca system szablonów Jinja2. Jinja2 to potężne narzędzie, ale jeśli jest używane do renderowania szablonów pochodzących z niezaufanego źródła, może prowadzić do wykonania dowolnego kodu Pythona na serwerze. Chociaż badacze nie znaleźli bezpośredniej ścieżki do RCE z samego wywołania funkcji load(), kolejne operacje na zdeserializowanym, złośliwym obiekcie mogły uruchomić ten proces. To ryzyko było na tyle poważne, że w ramach łatki domyślnie zablokowano inicjalizację szablonów Jinja2.

Strategie Ochrony i Rekomendowane Działania

Ochrona przed CVE-2025-68664 wymaga natychmiastowych i przemyślanych działań. Samo wdrożenie łatki to dopiero początek.

Krok 1: Natychmiastowa Aktualizacja

Priorytetem absolutnym jest aktualizacja biblioteki langchain-core do najnowszej, bezpiecznej wersji:

• Python: 1.2.5 lub nowsza (dla linii 1.x) / 0.3.81 lub nowsza (dla linii 0.x).
• JavaScript: @langchain/core do 1.1.8+ / langchain do 1.2.3+ (lub odpowiednich wersji dla starszych linii).

Uwaga: Kluczowe jest przeprowadzenie audytu zależności. Wiele bibliotek ekosystemu (langchain-community, langchain-openai itp.) zależy od langchain-core. Należy upewnić się, że wszystkie pakiety w projekcie korzystają z bezpiecznej wersji biblioteki, nawet jeśli jest to zależność pośrednia.

Krok 2: Zrozumienie Wzmocnień Wprowadzonych w Łatce

Twórcy LangChain zareagowali wzorowo, nie tylko naprawiając błąd, ale także wzmacniając domyślne ustawienia bezpieczeństwa:

• Poprawne escapowanie klucza 'lc': Główna poprawka, która uniemożliwia interpretowanie danych użytkownika jako obiektów systemowych.
• Ograniczona domyślna “biała lista”: Funkcje deserializacji domyślnie pozwalają teraz na tworzenie tylko podstawowych, bezpiecznych klas. Aby użyć innych, deweloper musi je jawnie zadeklarować.
• secrets_from_env=False domyślnie: Automatyczne ładowanie sekretów ze zmiennych środowiskowych jest teraz domyślnie wyłączone.
• Blokada Jinja2: Inicjalizacja szablonów Jinja2 jest domyślnie zablokowana, co eliminuje najpoważniejszy wektor ataku RCE.

Krok 3: Wdrożenie Strategii Obrony w Głąb (Defense-in-Depth)

Sama łatka to za mało. Każda organizacja budująca systemy AI powinna wdrożyć dodatkowe warstwy zabezpieczeń. Oto rekomendacje ekspertów VIPentest:

• Traktuj dane wyjściowe LLM jako niezaufane: To fundamentalna zmiana paradygmatu. Każdy tekst, metadane czy wynik działania narzędzia zwrócony przez model LLM musi być traktowany z taką samą ostrożnością jak dane wprowadzane przez anonimowego użytkownika w formularzu na stronie internetowej.
• Zasada najmniejszych uprawnień (Principle of Least Privilege): Aplikacje AI, a zwłaszcza autonomiczni agenci, muszą działać w ściśle kontrolowanym, odizolowanym środowisku (sandbox). Dostęp do kluczy API, baz danych czy systemów plików powinien być ograniczony do absolutnego minimum niezbędnego do wykonania zadania.
• Regularny audyt bezpieczeństwa: Konfiguracja mechanizmów serializacji i deserializacji powinna być regularnie przeglądana. Każde odstępstwo od bezpiecznych domyślnych ustawień musi być świadomą decyzją i odpowiednio udokumentowane.
• Monitoring i wykrywanie anomalii: Warto wdrożyć monitoring operacji serializacji, aby wykrywać podejrzane wzorce, takie jak próby tworzenia nietypowych obiektów czy odwoływania się do wrażliwych zmiennych środowiskowych.

Wnioski: Nowa Era Zagrożeń dla Aplikacji AI

Podatność CVE-2025-68664 to dzwonek alarmowy dla całej branży. Pokazuje, że w miarę jak systemy AI stają się coraz bardziej zintegrowane z naszą infrastrukturą IT, stają się również celem dla dobrze znanych, klasycznych technik ataków, które znajdują nowe, nieoczywiste wektory w złożonej architekturze tych systemów.

Ochrona LLM i aplikacji na nich opartych to już nie tylko kwestia walki z “halucynacjami” modeli czy prompt injection na poziomie treści. To także konieczność zabezpieczenia całej warstwy aplikacyjnej – od zarządzania zależnościami, przez bezpieczną konfigurację, aż po hardening infrastruktury. Dla firm w Polsce, które inwestują w innowacje oparte na AI, proaktywne podejście do cyberbezpieczeństwa jest warunkiem koniecznym do odniesienia sukcesu i budowania zaufania klientów. Regularne testy penetracyjne AI oraz audyty stają się nieodzownym elementem cyklu życia takich produktów.

Jak możemy pomóc?

Zabezpieczenie dynamicznie rozwijających się aplikacji opartych na sztucznej inteligencji wymaga specjalistycznej wiedzy i doświadczenia. W VIPentest łączymy głęboką znajomość klasycznych zagrożeń cyberbezpieczeństwa z ekspertyzą w zakresie unikalnych wektorów ataków na systemy AI/ML.

Nasz zespół może pomóc Twojej organizacji w:

• Przeprowadzeniu kompleksowych testów penetracyjnych aplikacji opartych na LLM, identyfikując podatności takie jak CVE-2025-68664 i inne.
• Wykonaniu audytu bezpieczeństwa architektury i konfiguracji Twoich systemów AI.
• Opracowaniu i wdrożeniu strategii hardeningu oraz najlepszych praktyk w zakresie bezpiecznego tworzenia oprogramowania (Secure SDLC) dla projektów AI.

Jeśli chcesz mieć pewność, że Twoje innowacyjne rozwiązania AI są odporne na najnowsze zagrożenia, skontaktuj się z nami. Porozmawiajmy o tym, jak możemy wesprzeć Twój biznes.

Skontaktuj się z naszym zespołem ekspertów: https://vipentest.com/kontakt