12 godzin i 31 minut.
Tyle czasu minęło między publikacją ostrzeżenia o CVE-2026-33626 w LMDeploy a pierwszą zarejestrowaną próbą eksploitacji w środowiskach-pułapkach Sysdig. Bez publicznego kodu demonstracyjnego. Atakujący zbudował działający atak z samego opisu ostrzeżenia — tak samo jak przy Marimo w niecałe dziesięć godzin.
To jest trzeci framework do serwowania modeli AI zaatakowany w tym miesiącu. Trzeci z rzędu. Sysdig mówi to wprost: "CVE-2026-33626 wpisuje się w wzorzec obserwowany przez nas wielokrotnie w przestrzeni infrastruktury AI przez ostatnie sześć miesięcy: krytyczne podatności w serwerach wnioskowania, bramkach modeli i narzędziach do orkiestracji agentów są uzbrajane w godziny od publikacji ostrzeżenia, niezależnie od rozmiaru i zasięgu instalacji."
Czym jest LMDeploy i dlaczego ma dostęp do wszystkiego
LMDeploy to zestaw narzędzi open source opracowany przez Shanghai AI Laboratory do kompresowania, wdrażania i serwowania dużych modeli językowych i modeli wizyjno-językowych. Używany przez organizacje budujące własną infrastrukturę wnioskowania AI — zamiast polegać na zewnętrznych API, uruchamiają modele lokalnie lub w chmurze przez LMDeploy.
Typowy węzeł serwujący modele wizyjno-językowe działa na instancji GPU w chmurze z szerokimi uprawnieniami IAM: dostęp do artefaktów modeli w S3, zbiorów danych treningowych, często z możliwością przejmowania ról między kontami chmurowymi. Do tego dochodzą wewnętrzne magazyny danych: Redis do buforowania promptów, MySQL lub PostgreSQL do pomiarów, wewnętrzne interfejsy sterujące HTTP.
Innymi słowami: węzeł LMDeploy to skrzynka z kluczami do dużej części infrastruktury chmurowej organizacji. Podatność w nim nie oznacza kompromitacji jednego serwisu — oznacza potencjalne przejęcie konta chmurowego.
Gdzie leży błąd
CVE-2026-33626 siedzi w module wizyjno-językowym LMDeploy, konkretnie w funkcji load_image() w pliku lmdeploy/vl/utils.py. Funkcja pobiera obrazy z podanych adresów URL, żeby przetworzyć je przez model wizyjny — standardowa operacja dla modeli przyjmujących obrazy jako wejście.
Problem polega na tym, że funkcja nie sprawdza czy podany URL wskazuje na zewnętrzny zasób czy na prywatne zasoby sieciowe. Atakujący może podać jako "obraz" adres URL wskazujący na usługę metadanych instancji AWS (169.254.169.254), wewnętrzny Redis, bazę danych MySQL, albo dowolny inny wewnętrzny zasób dostępny z węzła serwującego model. LMDeploy posłusznie pobierze odpowiedź i zwróci ją jako wynik przetwarzania.
Nie jest wymagane żadne uwierzytelnienie ponad standardowym dostępem do interfejsu API modelu. Nie jest potrzebny żaden specjalny ładunek. Wystarczy jedno żądanie z odpowiednio spreparowanym polem URL obrazu.
Podatność dotyczy wszystkich wersji zestawu narzędzi do 0.12.0 włącznie ze wsparciem dla modeli wizyjno-językowych.
Osiem minut, dziesięć żądań, pełna mapa wewnętrznej sieci
Zachowanie atakującego w pułapce Sysdig jest warte szczegółowego opisania, bo pokazuje jak profesjonalnie podchodzą do eksploitacji.
Atakujący nie sprawdził tylko czy podatność działa i nie przeszedł dalej. W ciągu ośmiu minut, przez dziesięć osobnych żądań, przeprowadził systematyczne rozpoznanie wewnętrznej sieci za serwerem modelu. Trzy fazy działania były wyraźne.
Faza pierwsza: weryfikacja zasięgu SSRF przez wywołanie zwrotne DNS do zewnętrznego serwisu requestrepo[.]com i wyliczenie powierzchni API. Potwierdzenie że podatność może docierać do zewnętrznych hostów.
Faza druga: atak na usługę metadanych instancji AWS (IMDS pod adresem 169.254.169.254) i próba wyciągnięcia tokenów IAM oraz danych uwierzytelniających chmurowych. Następnie skanowanie wewnętrznych usług: Redis na porcie 6379, MySQL na porcie 3306, dodatkowy interfejs administracyjny HTTP na porcie 8080.
Faza trzecia: sonda distserve/p2p_drop_connect — próba zerwania połączenia ZMQ między silnikami prefill i decode w architekturze rozproszonego serwowania LMDeploy. Atakujący rozumiał wewnętrzną architekturę frameworku i wiedział jak zakłócić wnioskowanie na tym węźle.
Sysdig podkreśla precyzję tego działania: przełączanie między różnymi modelami wizyjnymi (internlm-xcomposer2 i OpenGVLab/InternVL2-8B) w trakcie rozpoznania — prawdopodobnie żeby uniknąć wyzwolenia alertów opartych na wzorcach.
Trzecia z rzędu w tym samym miesiącu
Zestawienie trzech frameworków AI z kwietnia 2026 roku mówi samo za siebie.
Marimo CVE-2026-39987 — terminal WebSocket bez uwierzytelnienia, eksploitacja w 9 godzin i 41 minut, bez publicznego kodu demonstracyjnego. Klucze AWS i tokeny API wyciągnięte w trzy minuty.
SGLang CVE-2026-5760 — wstrzyknięcie szablonu przez plik modelu GGUF, ta sama klasa błędu co Llama Drama i vLLM wcześniej. Plik modelu jako złośliwe oprogramowanie.
LMDeploy CVE-2026-33626 — SSRF w ładowaniu obrazów przez moduł wizyjny, 12 godzin i 31 minut do pierwszej eksploitacji, systematyczne skanowanie wewnętrznej sieci w osiem minut.
Trzy różne klasy podatności — brak uwierzytelnienia, wstrzyknięcie szablonu, fałszowanie żądań po stronie serwera. Trzy różne frameworki. Ten sam wzorzec: infrastruktura AI serwująca modele jako cel ataków, eksploitacja w kilka godzin od ujawnienia, dostęp do zasobów chmurowych jako cel.
Sysdig wyciąga wniosek który bezpośrednio łączy się z tym co pisaliśmy przy zestawieniu Marimo i Flowise: "Dwunastogodzinne i trzydziestominutowe okno od publikacji do pierwszej obserwowanej eksploitacji LMDeploy jest wystarczająco krótkie, żeby cykle Patch Tuesday i miesięczne skanowania nie były wystarczającą kontrolą bezpieczeństwa."
Infrastruktura AI poza standardowym obiegiem bezpieczeństwa
Jest strukturalna przyczyna dla której te frameworki są podatne i dlaczego podatności są eksploitowane tak szybko.
Platformy do serwowania modeli — LMDeploy, vLLM, SGLang, Marimo, Flowise — są bardzo często wdrażane poza standardowym procesem przeglądu bezpieczeństwa i rzadko są objęte skanowaniem CVE aż do długo po ujawnieniu podatności. Organizacje traktują je jako narzędzia badawcze lub deweloperskie, nie jako elementy infrastruktury produkcyjnej wymagające zarządzania podatnościami.
Pisaliśmy o tym przy okazji Flowise — sześć miesięcy z dostępną poprawką, dwanaście do piętnastu tysięcy instancji wciąż podatnych, bo nikt nie traktował Flowise jako systemu wymagającego aktywnego zarządzania. LMDeploy jest tym samym wzorcem, tylko że eksploitacja nastąpiła w dwanaście godzin zamiast sześciu miesięcy.
Sysdig wskazuje na konkretny problem: loadery obrazów wizyjno-językowych, punkty końcowe narzędzi agentowych i pobieracze RAG są domyślnie kandydatami na SSRF, chyba że zastosowane jest jawne filtrowanie ruchu wychodzącego. W typowych wdrożeniach to filtrowanie nie istnieje — bo węzeł serwujący modele potrzebuje dostępu do internetu żeby pobierać modele, dane i obrazy. Granica między "legalny dostęp sieciowy" a "wektor SSRF" jest cienka i łatwa do przekroczenia.
Co zrobić
Aktualizacja do LMDeploy 0.13.0 lub nowszego usuwa podatność. Wersja ta dodaje walidację adresów URL w funkcji load_image() blokując żądania do prywatnych zakresów adresów IP.
Dla środowisk które nie mogą natychmiast zaktualizować: jawne filtrowanie ruchu wychodzącego na poziomie sieci blokujące dostęp węzłów serwujących modele do usługi metadanych instancji IMDS (169.254.169.254), wewnętrznych magazynów danych i innych zasobów dostępnych wyłącznie wewnętrznie — eliminuje główne cele SSRF nawet bez aktualizacji aplikacji.
Dla środowisk AWS: wyłączenie IMDSv1 i wymaganie IMDSv2 z tokenem sesji jako dodatkowa warstwa ochrony — żądania SSRF z aplikacji nie mogą automatycznie uzyskać tokenów IAM przez IMDSv2 bez dodatkowego nagłówka.
Jeśli węzeł LMDeploy był dostępny publicznie przed 21 kwietnia 2026 roku — należy przyjąć założenie możliwej kompromitacji i zrotować tokeny IAM, klucze dostępowe do chmury i dane uwierzytelniające do wewnętrznych usług dostępnych z tego węzła.
Podsumowanie
CVE-2026-33626 w LMDeploy to nie jest odizolowany incydent. To jest trzecia w ciągu miesiąca eksploitacja frameworku AI z podobnym wzorcem: infrastruktura do serwowania modeli jako cel, szybka eksploitacja bez publicznego kodu demonstracyjnego, dostęp do zasobów chmurowych jako główny cel.
Wzorzec jest teraz wystarczająco powtarzalny, żeby traktować go jako klasę ryzyka a nie serię przypadkowych incydentów. Każdy framework do serwowania modeli AI, który przetwarza zewnętrzne dane wejściowe i ma jednocześnie dostęp do wewnętrznej infrastruktury chmurowej, jest potencjalnym wektorem tego samego ataku — niezależnie od tego czy dostał już własne CVE.
Źródła
Sysdig Threat Research Team — pierwotna analiza z danymi z pułapek i chronologią ataku: https://webflow.sysdig.com/blog/cve-2026-33626-how-attackers-exploited-lmdeploy-llm-inference-engines-in-12-hours
The Hacker News — omówienie CVE-2026-33626 i kontekst eksploitacji: https://thehackernews.com/2026/04/lmdeploy-cve-2026-33626-flaw-exploited.html
Vulert — analiza techniczna klasy podatności SSRF i warunków eksploitacji: https://vulert.com/blog/lmdeploy-cve-2026-33626-ssrf/
