CVE-2026-76850
KrytyczneCVSS 9.8Prawdopodobieństwo exploitacji (EPSS)
Podwyższone ryzykoPercentyl 69 - wyżej niż 69% wszystkich znanych CVE
Streszczenie
LMDeploy deserializuje komunikaty peer-to-peer w trybie disaggregated serving za pomocą pickle. Funkcja handle_zmq_recv w lmdeploy/pytorch/disagg/conn/engine_conn.py odczytuje żądania cache-free przez recv_pyobj(), co deserializuje odebrane bajty przez pickle.loads(), a sprawdzenie isinstance przeciwko DistServeCacheFreeRequest następuje dopiero po zakończeniu deserializacji. Peer dostarczający te bajty jest kontrolowany przez wywołującego: p2p_connect przekazuje remote_engine_endpoint_info.zmq_address z treści żądania do connect() na gnieździe ZMQ PULL, a endpointy POST /distserve/p2p_initialize i /distserve/p2p_connect w lmdeploy/serve/openai/api_server.py nie stosują uwierzytelniania, chyba że serwer jest uruchomiony z api_keys, które domyślnie mają wartość None. Zdalny atakujący może skierować silnik do pobierania z kontrolowanego przez siebie punktu końcowego ZMQ i wykonać dowolny kod w procesie silnika. Wdrożenia, które nie włączają disaggregated serving, nie są dotknięte, ponieważ pętla odbioru jest uruchamiana tylko po zaakceptowaniu połączenia przez backend migracji.
Ocena ryzyka
Zdalny atakujący może wykonać dowolny kod w procesie silnika, co może prowadzić do pełnego przejęcia systemu lub naruszenia danych.
Rekomendacja
Zaktualizuj LMDeploy do wersji, która naprawia tę podatność, lub włącz uwierzytelnianie (api_keys) i ogranicz dostęp do endpointów p2p.
Inne podatności w LMDeploy
Zobacz wszystkie- CVE-2025-66455Krytyczne
LMDeploy w wersjach od 0.9.2 do 0.16.0 wykorzystywał funkcję recv_pyobj() do deserializacji komunikatów odbieranych przez gniazdo ZeroMQ PULL w płaszczyźnie sterowania DistServe/PD-disaggregation. Deserializacja pickle może wykonać dowolny kod, a adres peera był dostarczany przez endpoint HTTP POST /distserve/p2p_connect. Bez włączonego uwierzytelniania kluczem API atakujący mógł doprowadzić do zdalnego wykonania kodu z uprawnieniami procesu serwującego LMDeploy.
- CVE-2025-59953Krytyczne
LMDeploy implementuje serwer RPC (AsyncRPCServer w zmq_rpc.py), który w funkcji call_and_response() deserializuje otrzymane wiadomości za pomocą pickles.loads() bez żadnej sanityzacji. Umożliwia to zdalne wykonanie kodu przez ten serwer RPC. Podatność występuje od wersji 0.9.1 do 0.10.2, gdzie została naprawiona.
- CVE-2026-33625Wysokie
LMDeploy w wersjach 0.12.1 do 0.12.2 zawiera lukę wstrzyknięcia kodu w pliku lmdeploy/pytorch/config.py w linii 620. Atakujący może wykonać dowolny kod Python, publikując złośliwy model HuggingFace ze spreparowaną wartością quantization_config.quant_dtype, która jest przekazywana do eval() bez walidacji.
- CVE-2026-92983Wysokie
InternLM LMDeploy do wersji 0.17.0 w trybie rozdzielenia prefill/decode DistServe nie zwalnia sesji schedulera, ponieważ proxy używa identyfikatorów sesji widocznych dla użytkownika zamiast wewnętrznych kluczy schedulera. Nieuwierzytelnieni atakujący mogą wysyłać żądania ukończenia do endpointu proxy, co kumuluje niezwolnione metadane i pamięć aż do zabicia workera prefill przez brak pamięci.
- CVE-2026-63764Wysokie
Podatność SSRF w LMDeploy do wersji 0.14.0 (załatana w commit 03c3130) w funkcji _load_http_url w connection.py. Mechanizm ochrony przed adresami prywatnymi sprawdza tylko oryginalny URL, nie weryfikując hostów po przekierowaniach HTTP.
- CVE-2026-46517Wysokie
LMDeploy to zestaw narzędzi do kompresji, wdrażania i serwowania dużych modeli językowych. W wersjach 0.12.3 i wcześniejszych, zakodowane na stałe "trust_remote_code=True" umożliwia zdalne wykonanie kodu (RCE) w łańcuchu dostaw HF bez zgody użytkownika. Wersja 0.13.0 naprawia ten problem.
- CVE-2026-46432Wysokie
LMDeploy w wersjach do 0.12.3 zawiera zakodowane na stałe ustawienie "trust_remote_code=True" w wielu miejscach ładowania modeli HuggingFace, co umożliwia zdalne wykonanie dowolnego kodu. W chwili publikacji nie są dostępne żadne publiczne łatki.
Oryginalny opis (angielski, źródło NVD)
LMDeploy deserializes disaggregated-serving peer messages with pickle. The handle_zmq_recv coroutine in lmdeploy/pytorch/disagg/conn/engine_conn.py reads peer-to-peer cache-free requests with recv_pyobj(), which deserializes the received bytes with pickle.loads(), and the isinstance check against DistServeCacheFreeRequest runs only after deserialization has already completed. The peer that supplies those bytes is caller-controlled: p2p_connect passes remote_engine_endpoint_info.zmq_address from the request body to connect() on the ZMQ PULL socket, and the POST /distserve/p2p_initialize and /distserve/p2p_connect endpoints in lmdeploy/serve/openai/api_server.py apply no authentication unless the server is started with api_keys, which defaults to None. A remote attacker can direct an engine to pull from a ZMQ endpoint under their control and execute arbitrary code in the engine process. Deployments that do not enable disaggregated serving are not affected, because the receive loop is only started once the migration backend accepts the connection.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS