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

Krytyczna luka w Ollama umożliwia zdalny wyciek pamięci procesu

Wprowadzenie do problemu / definicja

Wraz z rosnącą popularnością lokalnie uruchamianych modeli językowych bezpieczeństwo infrastruktury AI staje się równie ważne jak ochrona klasycznych aplikacji serwerowych. Najnowsze ustalenia badaczy wskazują na krytyczną podatność w Ollama, popularnym narzędziu do uruchamiania modeli LLM lokalnie oraz przez API.

Luka została oznaczona jako CVE-2026-7482 i dotyczy błędu odczytu poza zakresem pamięci procesu. W praktyce oznacza to, że zdalny, nieuwierzytelniony atakujący może doprowadzić do ujawnienia danych znajdujących się w pamięci usługi, jeśli instancja jest dostępna z sieci.

W skrócie

Podatność oznaczono jako CVE-2026-7482.
Poziom zagrożenia oceniono jako krytyczny, z wynikiem 9.1 w skali CVSS.
Problem dotyczy wersji Ollama wcześniejszych niż 0.17.1.
Atak wykorzystuje obsługę plików GGUF oraz endpoint /api/create.
Skutkiem może być wyciek danych z pamięci procesu, w tym sekretów i treści przetwarzanych przez model.

Kontekst / historia

Ollama zdobyła popularność jako rozwiązanie upraszczające lokalne uruchamianie modeli językowych bez konieczności korzystania z chmury publicznej. Z tego powodu narzędzie jest często używane w środowiskach deweloperskich, laboratoriach AI, wewnętrznych wdrożeniach firmowych oraz integracjach z agentami i systemami automatyzacji.

Wiele organizacji wystawia jednak interfejs API do sieci, aby przyspieszyć integrację z aplikacjami lub usługami pośredniczącymi. To właśnie taki model wdrożenia zwiększa ryzyko wykorzystania opisywanej luki, ponieważ podatność może zostać użyta bez logowania, jeśli usługa jest osiągalna z zewnątrz.

Znaczenie problemu wykracza poza zwykłą destabilizację procesu. W tym przypadku zagrożona jest poufność danych, a więc nie tylko konfiguracja hosta, ale również prompty systemowe, kontekst rozmów, odpowiedzi modeli, tokeny oraz informacje przetwarzane równolegle przez inne zadania.

Analiza techniczna

Źródłem podatności jest błąd typu out-of-bounds read w mechanizmie ładowania modeli GGUF oraz w ścieżce związanej z przetwarzaniem i kwantyzacją modelu. Aplikacja akceptuje plik GGUF dostarczony przez użytkownika, a następnie interpretuje metadane opisujące położenie i rozmiary tensorów.

Jeżeli te wartości zostaną celowo sfałszowane i wskażą obszary wykraczające poza rzeczywistą zawartość pliku, serwer może odczytać dane spoza przewidzianego bufora. Problem jest szczególnie groźny, ponieważ występuje w obszarze wykorzystującym operacje niskopoziomowe, co ogranicza ochronę typową dla bezpieczniejszych mechanizmów zarządzania pamięcią.

Scenariusz ataku jest relatywnie prosty. Napastnik dostarcza spreparowany plik GGUF do instancji Ollama, a następnie uruchamia proces tworzenia modelu przez endpoint /api/create. W wadliwej ścieżce przetwarzania aplikacja może wczytać fragmenty pamięci sterty i zapisać je do tworzonego artefaktu modelu, który następnie może zostać wyprowadzony poza środowisko ofiary.

To sprawia, że wyciek obejmuje potencjalnie nie tylko dane samego procesu, ale też informacje pochodzące z aktywnych sesji użytkowników, integracji narzędziowych i zewnętrznych komponentów podłączonych do serwera LLM. W środowiskach produkcyjnych skala takiego incydentu może być znacznie większa niż w typowych aplikacjach testowych.

Konsekwencje / ryzyko

Największym zagrożeniem jest utrata poufności. W pamięci procesu mogą znajdować się klucze API, tokeny dostępowe, zmienne środowiskowe, dane klientów, fragmenty kodu, treści dokumentów biznesowych oraz zapis konwersacji z modelem.

Ryzyko istotnie rośnie, gdy instancja Ollama jest publicznie dostępna albo udostępniona wewnętrznie bez segmentacji sieci i dodatkowej warstwy uwierzytelniania. W takich przypadkach pojedyncza luka może stać się punktem wejścia do szerszego incydentu obejmującego wiele aplikacji korzystających z tego samego backendu AI.

Szczególnie niebezpieczny jest też charakter eksfiltracyjny podatności. Organizacja może nie zauważyć ataku od razu, ponieważ nie musi on powodować awarii, zakłóceń usług ani innych wyraźnych objawów operacyjnych. W praktyce możliwy jest cichy wyciek danych poprzez utworzony artefakt modelu.

Rekomendacje

Najważniejszym krokiem jest niezwłoczna aktualizacja Ollama do wersji 0.17.1 lub nowszej, zawierającej poprawkę bezpieczeństwa. Sama aktualizacja nie powinna jednak być jedynym środkiem zaradczym, ponieważ duża część ryzyka wynika również z niewłaściwej ekspozycji usługi.

Ograniczyć dostęp do API wyłącznie do zaufanych segmentów sieci.
Ukryć usługę za firewallem, reverse proxy lub API gateway.
Wymusić uwierzytelnianie i autoryzację dla operacji administracyjnych oraz tworzenia modeli.
Zablokować import modeli i artefaktów z niezaufanych źródeł.
Monitorować użycie endpointów takich jak /api/create oraz operacje publikacji artefaktów.
Przeprowadzić audyt sekretów i zmiennych środowiskowych dostępnych dla procesu.
Ograniczyć uprawnienia procesu i uruchamiać usługę w możliwie odizolowanym środowisku.
Analizować logi pod kątem nietypowych operacji tworzenia modeli i połączeń wychodzących.

W środowiskach produkcyjnych warto również traktować serwery LLM jako systemy wysokiego ryzyka dla danych. Oznacza to potrzebę klasyfikacji przetwarzanych informacji, ograniczania czasu życia sekretów, separacji tenantów oraz kontroli przepływu danych pomiędzy użytkownikami, agentami i narzędziami.

Podsumowanie

CVE-2026-7482 pokazuje, że platformy AI uruchamiane lokalnie mogą zawierać klasyczne błędy bezpieczeństwa o bardzo poważnych skutkach biznesowych. W przypadku Ollama problem ma charakter krytyczny, ponieważ umożliwia zdalny i nieuwierzytelniony wyciek pamięci procesu poprzez spreparowany plik modelu i otwarty interfejs API.

Dla organizacji korzystających z lokalnych modeli językowych to wyraźny sygnał, że bezpieczeństwo warstwy inferencyjnej musi być oceniane tak samo rygorystycznie jak bezpieczeństwo aplikacji produkcyjnych. Szybkie wdrożenie poprawek, ograniczenie ekspozycji sieciowej i wzmocnienie kontroli dostępu powinny być w tym przypadku absolutnym priorytetem.

Źródła

The Hacker News — https://thehackernews.com/2026/05/ollama-out-of-bounds-read-vulnerability.html
CVE Record: CVE-2026-7482 — https://www.cve.org/CVERecord?id=CVE-2026-7482
Cyera Research — Bleeding Llama: Critical Unauthenticated Memory Leak in Ollama — https://www.cyera.com/research/bleeding-llama-critical-unauthenticated-memory-leak-in-ollama
Ollama Releases — https://github.com/ollama/ollama/releases

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

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

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

Infosecurity Magazine — OpenAI and Anthropic LLMs Used in Critical Infrastructure Cyber-Attack, Warns Dragos — https://www.infosecurity-magazine.com/news/llm-critical-infrastructure/
Dragos — OT Threat Landscape 2026: What Defenders Need to Know — https://www.dragos.com/blog/ot-threat-landscape-2026
Dragos — Dragos 2026 OT Cybersecurity Report Year in Review — https://hub.dragos.com/hubfs/2026_YIR_ExecutiveBriefing%20O_G.pdf?hsLang=en
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/
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

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

Security Affairs — https://securityaffairs.com/191483/hacking/cve-2026-42208-litellm-bug-exploited-36-hours-after-its-disclosure.html
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
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

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

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

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

LiteLLM: SQL injection in Proxy API key verification — https://github.com/BerriAI/litellm/security/advisories/GHSA-r75f-5x8p-qvmc
BerriAI/litellm repository — https://github.com/BerriAI/litellm
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/
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/
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

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.