CVE-2026-33626 w LMDeploy: luka SSRF wykorzystana kilkanaście godzin po ujawnieniu - Security Bez Tabu

CVE-2026-33626 w LMDeploy: luka SSRF wykorzystana kilkanaście godzin po ujawnieniu

Cybersecurity news

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.

Źródła