SGLang CVE-2026-93034: wyłączenie pickle IPC nie wystarcza

8 października opublikowano CVE-2026-93034 dotyczące SGLang. Rekord CERT/CC opisuje niebezpieczną deserializację w komunikacji ZeroMQ, obecną także po wyłączeniu SGLANG_USE_PICKLE_IPC. Zdalna eksploatacja wymaga włączonego data-parallel attention i adresu --dist-init-addr poza loopback. Zakres podatnych wersji obejmuje wydania do v0.5.20 włącznie; sprawdzony rekord nie wskazuje wersji naprawionej. Źródło: rekord CVE opublikowany przez CERT/CC.

Wniosek Breachroad: zespół utrzymujący serwery modeli powinien zweryfikować konfigurację i osiągalność komunikacji między węzłami. Samo ustawienie flagi środowiskowej nie stanowi wystarczającego dowodu usunięcia opisanej ścieżki. Nie każde wdrożenie SGLang spełnia warunki zdalnego wykorzystania, a adres poza loopback nie oznacza automatycznie dostępności z internetu.

Co pokazuje kod, a co z tego wynika

W kodzie oznaczonym tagiem v0.5.20 dekoder msgpack może zwrócić obiekt PickleWrapper. Funkcja _maybe_unwrap_pickle przekazuje jego dane do pickle.loads. Gałąź odbioru używająca msgpack nadal wywołuje tę funkcję, gdy flaga pickle IPC jest wyłączona.

To odczyt konkretnego pliku źródłowego, nie wynik testu każdego wariantu wdrożenia. Nasza interpretacja: trzeba ocenić cały przepływ danych do deserializacji, zamiast wnioskować o bezpieczeństwie wyłącznie z nazwy formatu zewnętrznej wiadomości. Dane opakowane w msgpack mogą w tym przepływie uruchomić kolejny mechanizm odczytu.

Dokumentacja Pythona ostrzega, że deserializacja niezaufanych danych pickle może wykonać kod. W naszej ocenie dostęp do kanału komunikacji procesu trzeba więc potraktować jako istotną granicę uprawnień, a nie wyłącznie kwestię wydajności serwera AI.

Trzy ustalenia przed zamknięciem zgłoszenia

Poniższe kroki są rekomendacją Breachroad dla administratorów i zespołów MLOps:

1. Zidentyfikuj działający komponent. Zapisz wersję rzeczywiście uruchomionego pakietu lub obrazu, konfigurację procesu oraz właściciela usługi. Nie ograniczaj się do pliku zależności w repozytorium: środowisko produkcyjne może mieć inną historię aktualizacji.
2. Wyznacz dozwolonych nadawców. Sprawdź, które systemy mogą dotrzeć do kanałów komunikacji między węzłami. Uwzględnij inne obciążenia w klastrze, połączenia administracyjne i środowiska współdzielone. Nazwa „sieć wewnętrzna” nie opisuje jeszcze rzeczywistego zakresu dostępu.
3. Udokumentuj decyzję o ograniczeniu ryzyka. Określ oczekiwane węzły, ogranicz pozostałe połączenia odpowiednimi regułami sieciowymi i potwierdź działanie potrzebnych funkcji. Zapisz osobę odpowiedzialną oraz termin ponownej oceny informacji od projektu.

Nie podajemy numeru aktualizacji jako rozwiązania, ponieważ sprawdzony rekord nie identyfikuje poprawki. Przy wyborze wydania wymagaj potwierdzenia od projektu, że obejmuje ono ten problem, oraz sprawdzenia właściwej ścieżki w swoim środowisku. Sam wyższy numer wersji nie wyjaśnia, co zostało zmienione.

Wynik powinien rozróżniać uruchomioną wersję, osiągalne systemy, ograniczenia sieciowe i dowód poprawienia kodu. To odrębne ustalenia. Pozostawienie otwartego pytania ułatwia kolejny przegląd bardziej niż zamknięcie całego zgłoszenia po zmianie jednego ustawienia.

Przykład: ten sam model, inny zakres dostępu

Wyobraźmy sobie dwa zespoły udostępniające identyczny model. Pierwszy potrafi wskazać węzły usługi i wykazać, że komunikacja robocza jest ograniczona do nich. Drugi współdzieli sieć z aplikacjami innych działów i nie ma listy dozwolonych nadawców. To przykład szkoleniowy, nie opis konkretnych poszkodowanych.

Nasza rekomendacja dla drugiego zespołu: najpierw ustalić zakres osiągalności i właściciela ograniczeń, a następnie zweryfikować zmianę. Zespołu pierwszego nie zwalnia to z oceny podatności. Ograniczenie dostępu i poprawienie podatnego kodu to różne dowody, które powinny być widoczne w zgłoszeniu.

Jak traktować podejrzenie naruszenia

Jeżeli analiza pokaże nieoczekiwane połączenia lub działania procesu, uruchom firmową obsługę incydentu. Zalecamy zachowanie logów, konfiguracji i osi czasu dostępności usługi oraz ustalenie, do jakich zasobów miało dostęp jej konto. Decyzje o izolacji i zmianie poświadczeń powinny uwzględniać ten zakres. Nie zakładaj, że usunięcie pojedynczego połączenia wyjaśnia wszystkie wcześniejsze zdarzenia.

Ta podatność przypomina, że bezpieczeństwo AI obejmuje również procesy serwera, sieć i uprawnienia. Więcej kontekstu znajdziesz w przewodniku po bezpieczeństwie LLM w firmie. Zespoły wdrażające modele mogą przećwiczyć podobne decyzje podczas szkoleń z cyberbezpieczeństwa i bezpiecznego AI dla organizacji.