Podatności vLLM

Podatność w vLLM w wersjach od 0.3.0 do 0.22.0 pozwala na obejście uwierzytelniania API OpenAI AuthenticationMiddleware. Atakujący może korzystać z API bez podania skonfigurowanego klucza VLLM_API_KEY lub --api-key.

Podatność w vLLM od wersji 0.8.3 do 0.14.0 pozwala na wyciek adresu sterty poprzez wysłanie nieprawidłowego obrazu do endpointu multimodalnego. Wyciek ten redukuje skuteczność ASLR z 4 miliardów do około 8 prób, co ułatwia przeprowadzenie ataku.

vLLM w wersjach od 0.16.0 do 0.32.0 pozwala uwierzytelnionemu użytkownikowi na umieszczenie kontrolowanego przez atakującego szablonu w chat_template_kwargs[chat_template], gdy nie skonfigurowano szablonu serwera. Funkcja ChatParams.get_apply_chat_template_kwargs() zachowuje tę wartość bez egzekwowania trust_request_chat_template, co pozwala obejść politykę zaufania i spowodować wyczerpanie CPU lub pamięci przez renderowanie Jinja.

vLLM przed wersją 0.32.0 konfiguruje Starlette CORSMiddleware z allowed_origins ustawionym domyślnie na wildcard. Złośliwa strona internetowa może za pośrednictwem przeglądarki ofiary uzyskać dostęp do nieuwierzytelnionego serwera vLLM w localhost, sieci wewnętrznej lub VPN i wywoływać punkty końcowe, zużywając zasoby GPU i odczytując odpowiedzi.

vLLM przed wersją 0.32.0 w pliku vllm/tokenizers/hf.py oblicza max_token_id z błędem off-by-one górnej granicy, pozwalając identyfikatorowi tokenu równego rozmiarowi słownika przejść walidację. Przy rozmiarze tensor-parallel równym jeden i słowniku będącym wielokrotnością 64, VocabParallelEmbedding.forward nie maskuje tej wartości przed użyciem w F.embedding, powodując asercję po stronie urządzenia CUDA i zakończenie silnika.

vLLM przed wersją 0.32.0 przekazuje bajty obrazów kontrolowane przez atakującego do biblioteki Pillow przez Image.open(BytesIO(data)) bez ograniczenia wyboru dekodera, a etykieta MIME nie ogranicza wybranego formatu. Ścieżki żądań obsługujące obrazy przez parse_image() i fetch_image() mogą skierować ładunek EPS do komponentów hosta, co przy podatnym Ghostscript (CVE-2024-29510) pozwala na wykonanie poleceń z uprawnieniami procesu vLLM, a przy Pillow 12.0.0–12.2.0 może wyczerpać wątki ładowania mediów.

vLLM w wersjach od 0.11.1 do 0.32.0 w ścieżce obrazów DeepSeek-OCR, DeepSeek-OCR-2 i Unlimited-OCR pozwala zdalnemu klientowi z dostępem do API zgodnego z OpenAI przesłać prawidłowy obraz, którego znormalizowane piksele sumują się do zera, gdy obraz jest sam w partii enkodera. _parse_and_validate_image_input zwraca brak osadzenia, embed_multimodal propaguje tę wartość, a sanity_check_mm_encoder_outputs wyzwala krytyczną asercję, wyłączając silnik dla wszystkich użytkowników.

vLLM to silnik wnioskowania i serwowania dużych modeli językowych. Przed wersją 0.32.0 enkoder audio Phi-4 w plikach phi4mm_audio.py i phi4mm_utils.py domyślnie używa eager attention, co pozwala zdalnemu klientowi przesłać jeden długi klip audio powodujący materializację pełnych macierzy uwagi i kwadratowe zużycie pamięci GPU, prowadząc do wyczerpania pamięci i zakończenia EngineCore dla wszystkich użytkowników.

W vLLM przed wersją 0.32.0 uwierzytelniony wywołujący może umieścić sfałszowane wartości adresu pamięci współdzielonej i monotonic_id w publicznym polu multimodal features.kwargs_data. W wdrożeniach scale-out z włączonym buforowaniem pamięci współdzielonej workery ufają tym wartościom i przekazują wybrane przez atakującego bajty do pickle.loads(), co pozwala na dowolne wykonanie kodu w Pythonie.

vLLM to silnik wnioskowania i serwowania dużych modeli językowych. Od wersji 0.19.0 do 0.32.0 uwierzytelnieni klienci mogą dostarczyć szablon czatu, gdy nie skonfigurowano serwerowego --chat-template, albo złośliwe repozytorium modelu może dostarczyć szablon kompilowany i renderowany przez tokenizer.apply_chat_template() bez limitu czasu, rozmiaru wyjścia ani liczby iteracji. Renderowanie odbywa się w ThreadPoolExecutor z jednym workerem, więc nieskończone renderowanie może zablokować /v1/responses i innych użytkowników szablonów, a rozszerzające wyjście może wyczerpać pamięć serwera.

vLLM od wersji 0.20.1 przed 0.29.0 zawiera podatność na niewłaściwą walidację danych wejściowych, która pozwala zdalnym atakującym na zawieszenie silnika poprzez podanie stop_token_ids spoza słownika. Atakujący może wysłać żądania OpenAI chat, completion, generate lub batch z nieprawidłowymi identyfikatorami, aby zakończyć działanie silnika lub zapisać poza buforem logits runnera V2.

vLLM od wersji 0.8.5 przed 0.31.0 zawiera podatność odmowy usługi. LogprobsTensors.empty_cpu() w vllm/v1/outputs.py alokuje niezainicjalizowany tensor int32, a runner modelu V1 pozostawia pozycje promptu raportowane jako obliczone przez łącznik KV jako niezapisane. Klient współdzielący silnik może wysłać prompt_logprobs (lub echo z logprobs) przeciwko prefiksowi buforowanemu przez łącznik, powodując wyjątek OverflowError w dekoderze tokenizera, który crashuje EngineCore i odrzuca wszystkie żądania współdzierżawców.

vLLM w wersjach od 0.18.0 przed 0.31.0 zawiera podatność na wyczerpanie zasobów, która pozwala klientom API obejść limit liczby klatek wideo/JPEG poprzez nadpisanie num_frames w media_io_kwargs. Atakujący może ustawić num_frames na -1 z dużym wideo inline, co powoduje dekodowanie każdej klatki przez VideoMediaIO.load_base64, wyczerpanie pamięci i awarię frontendu API.

vLLM od wersji 0.20.0 przed 0.30.0 zawiera podatność na odmowę usługi, która pozwala zdalnym atakującym na zawieszenie silnika poprzez wysłanie niespójnych metadanych multimodalnych do endpointu /inference/v1/generate. Atakujący może odtworzyć prawidłowy element multimodalny z powtórzonymi lub nakładającymi się zakresami mm_placeholders lub niezgodnymi listami kwargs_data i mm_hashes, tworząc ujemny zakres tekstu w konstrukcji pozycji Qwen2.5-VL, co kończy działanie silnika.

vLLM w wersjach od 0.10.2 przed 0.25.0 zawiera podatność na niekontrolowane zużycie zasobów, która pozwala nieuwierzytelnionym atakującym wyczerpać pamięć, ponieważ procesory Nemotron-VL globalnie ustawiają Image.MAX_IMAGE_PIXELS na None. Atakujący może przesłać obraz typu bomba dekompresyjna do /v1/chat/completions, co powoduje zabicie procesu roboczego przez OOM i odmowę usługi dla współlokatorów.

vLLM w wersjach od 0.9.2 przed 0.24.0 zawiera podatność typu server-side request forgery, która pozwala wywołującym API wymusić połączenia wychodzące poprzez osadzenie adresu dekodowania w nagłówku X-Request-Id. Atakujący może zmusić proces roboczy P2pNcclConnector prefill do połączenia ZMQ z hostem atakującego, wyciekając unikalny identyfikator NCCL i tensory KV-cache lub blokując proces roboczy.

vLLM od wersji 0.19.0 przed 0.24.0 zawiera podatność typu decompression bomb, ponieważ ścieżka multimodalna AudioMediaIO wywołuje load_audio bez limitu max_duration_s dekodowanego czasu trwania. Uwierzytelnieni atakujący mogą wysłać małe skompresowane audio przez input_audio lub audio_url w żądaniach /v1/chat/completions, które rozszerza się do ogromnego PCM, wyczerpując pamięć serwera.

vLLM od wersji 0.22.0 przed 0.24.0 zawiera podatność na niewłaściwą walidację danych wejściowych w usłudze Rust gRPC Generate i GenerateStream, która przekazuje niezweryfikowane identyfikatory tokenów promptu do EngineCore. Atakujący może wysłać żądania z wartościami prompt.token_ids spoza słownika, wywołując krytyczny błąd wyszukiwania osadzeń, który kończy EngineCore i pozostawia serwer w stanie niezdrowym.

vLLM od wersji 0.22.0 przed 0.24.0 zawiera podatność na odmowę usługi, która pozwala zdalnym atakującym na zakończenie EngineCore poprzez obejście limitów logprob_token_ids w frontendzie Rust gRPC. Atakujący może wysłać żądania Generate lub GenerateStream z włączonym output_logprobs i więcej niż 128 output_candidates.token_ids, wywołując krytyczny wyjątek próbkowania, który zawiesza silnik.

vLLM od wersji 0.22.0 przed 0.24.0 zawiera podatność na niewłaściwą walidację danych wejściowych w konwerterze Rust gRPC, która pozwala zdalnym atakującym na obejście limitów max_logprobs poprzez CandidateTokens.top_n. Atakujący może wysłać żądania Generate lub GenerateStream z nadmiernymi lub przepełniającymi się wartościami top_n, wywołując błędy torch.topk, które kończą EngineCore.

vLLM od wersji 0.7.3 przed 0.31.0 zawiera podatność na niekontrolowane zużycie zasobów. Zdalni klienci mogą kontrolować parametry procesora multimodalnego, dostarczając mm_processor_kwargs w każdym żądaniu. Atakujący mogą ustawić duże wartości rozmiaru obrazu, liczby patchy, przycięć lub klatek w procesorach Isaac, InternVL, H2OVL i innych, aby wyczerpać pamięć i zatrzymać współdzielony serwer.

vLLM w wersjach przed 0.31.0 zawiera podatność aliasingu pamięci podręcznej, która pozwala uwierzytelnionym atakującym kolidować współdzielone klucze pamięci podręcznej poprzez dostarczanie wartości kontrolowanych przez wywołującego, takich jak EXIF ImageID lub cache_salt. Atakujący może ustawić UUID EXIF ImageID, aby otrzymać przetworzone media z pamięci podręcznej innego żądania, lub dopasować cache_salt do nazwy LoRA, aby ponownie użyć stanu KV pierwszego bloku.

vLLM od wersji 0.7.3 przed 0.31.0 przekazuje wartość mm_processor_kwargs.code_revision dostarczoną w żądaniu do Transformers AutoProcessor.from_pretrained. Pozwala to klientom wybrać wersję dynamicznego kodu procesora modelu, która jest importowana, gdy trust_remote_code jest włączone. Atakujący kontrolujący wersję w repozytorium modelu może wysłać żądanie multimodalne do nieuwierzytelnionego endpointu /tokenize, aby wykonać dowolny kod Python w procesie API vLLM.

vLLM po wersji 0.24.0 i przed 0.31.0 zawiera podatność na wyczerpanie pamięci w obsłudze modelu MOSS-Audio. Serwer buforuje procesor dla każdej unikalnej wartości mm_processor_kwargs kontrolowanej przez żądanie w nieograniczonym słowniku. Nieuwierzytelnieni atakujący mogą wysyłać różne lub zbyt duże wartości mel_config do endpointu /tokenize, który omija --api-key, aby wyczerpać pamięć hosta i spowodować awarię procesu API.

vLLM przed wersją 0.31.0 pomija sprawdzenie min_tokens <= max_tokens dla żądań /inference/v1/generate z wartością max_tokens równą null. W rezultacie wątek wejściowy EngineCore kończy działanie z powodu nieobsłużonego VLLMValidationError, podczas gdy /health nadal zwraca 200. Nieuwierzytelnieni zdalni atakujący mogą wysłać jedno żądanie z nadmiernym min_tokens, aby zawiesić wszystkie kolejne żądania generowania aż do ręcznego restartu.

vLLM przed wersją 0.31.0 używa identyfikatora UUID multimodalnego dostarczonego przez klienta bezpośrednio jako tożsamości pamięci podręcznej, bez sprawdzania spójności przy trafieniach w pamięć podręczną. Może to powodować awarie silnika. Nieuwierzytelnieni atakujący mogą zdesynchronizować pamięci podręczne procesorów P0/P1, aby wywołać krytyczną niezgodność tokenów zastępczych, zabijając całą instancję serwera aż do restartu.

vLLM przed wersją 0.31.0 zawiera wyciek maski między żądaniami w InputBatch.condense(), który pozwala zdalnym atakującym ograniczyć wyniki innych klientów poprzez pozostawienie nieaktualnych wierszy allowed_token_ids. Atakujący mogą wysyłać równoczesne ograniczone żądania generowania, w tym przez nieuwierzytelnione /invocations, tak aby recyklingowane sloty wsadowe stosowały ich listę dozwolonych tokenów do nieograniczonych żądań ofiar.

vLLM przed 0.29.0 przekazuje przesłane audio do fallbacku PyAV/FFmpeg av.open() tylko z kontrolą rozmiaru pliku, narażając parser IAMF FFmpeg na przepełnienie sterty. Uwierzytelnieni zdalni atakujący mogą wielokrotnie przesyłać uszkodzone kontenery IAMF do /v1/audio/transcriptions, uszkadzając stertę i powodując awarię procesu API.

W projekcie vllm-project vLLM do wersji 0.31.0 odkryto lukę bezpieczeństwa w funkcji get_token_bin_counts_and_mask pliku vllm/model_executor/layers/utils.py komponentu Penalty Handler. Manipulacja prowadzi do odmowy usługi (DoS). Atak może być przeprowadzony zdalnie, a exploit został opublikowany.

Podatność w vllm-project vLLM do wersji 0.31.0 powoduje odczyt poza zakresem w funkcji conv_ssm_forward w pliku mamba_mixer2.py, w komponencie Completions Request Handler. Atak może być przeprowadzony zdalnie, a exploit został publicznie ujawniony.

W vLLM przed wersją 0.30.0, wywołujący może użyć pola media_io_kwargs do wybrania backendu wideo GLMGA i podać duże wartości fps i max_frames bez ścisłego limitu pracy, co prowadzi do nadmiernego zużycia CPU i pamięci.

W vLLM przed wersją 0.30.0, middleware track_http_metrics w Rust frontendzie rejestruje surowy token metody HTTP jako etykietę Prometheus dla żądań do zarejestrowanych tras, co pozwala nieuwierzytelnionemu atakującemu na tworzenie unikalnych etykiet i zwiększanie zużycia pamięci.

W vLLM od wersji 0.24.0 do 0.30.0, klasy Qwen2VLVideoBackend i Qwen3VLVideoBackend akceptują wartości max_frames i fps z żądania bez narzucania limitów serwerowych, co pozwala nieuwierzytelnionemu wywołującemu na dekodowanie każdej klatki z kontrolowanego wideo i zużywanie nadmiernej pamięci.

W vLLM przed wersją 0.30.0, błędy w żądaniach z ograniczeniami struktury mogą uciec z walidacji i trafić do ścieżki błędu krytycznego EngineCore, co pozwala zwykłym żądaniom z ograniczeniami na przerwanie działania współdzielonego silnika.

W vLLM przed wersją 0.30.0, modele żądań zgodne z OpenAI akceptują niepustą wartość cache_salt bez egzekwowania ograniczeń znaków i długości wymaganych przez IPCCacheServerKey w LMCache-MP, co może prowadzić do nieobsłużonego ValueError i przerwania działania EngineCore.

W vLLM przed wersją 0.30.0, scoring late-interaction na /score i /rerank wyprowadza query_key z nagłówka X-Request-Id kontrolowanego przez wywołującego, co pozwala współbieżnemu żądaniu na nadpisanie zakodowanego zapytania ofiary.

W vLLM przed wersją 0.30.0, endpoint /inference/v1/generate w ścieżce disaggregated scale-out akceptuje tensory, identyfikatory cache, zakresy i procesory pól multimodalnych kontrolowane przez wywołującego bez powiązania ich z kontraktem renderera, co może prowadzić do przerwania EngineCore, zatrucia cache lub zmiany semantyki transportu.

W vLLM przed wersją 0.28.0, domyślny lustrzany multimodalny LRU cache może zatwierdzić hash mediów w cache wysyłającym frontendu podczas renderowania multimodalnego, zanim żądanie zostanie zaakceptowane przez silnik, a jeśli żądanie jest odrzucone, cache odbierający nie otrzyma payloadu, co prowadzi do błędu asercji przy późniejszym użyciu tego samego hasha.

vLLM to silnik wnioskowania i obsługi dużych modeli językowych. W wersjach przed 0.30.0 kontynuacje narzędzi Harmony przesyłane przez żądania POST /v1/responses odbudowują dane wejściowe silnika na następną turę bez zachowania wartości cache_salt, umieszczając prefiks kontynuacji w globalnej niesolonej przestrzeni nazw pamięci podręcznej, nawet gdy wywołujący włączył solenie. W środowiskach z włączonym buforowaniem prefiksów (domyślnie) uwierzytelniony najemca może odtworzyć historię ofiary i użyć licznika cached_tokens_per_turn do ustalenia, czy prefiks był wcześniej przetwarzany, naruszając izolację najemców.

Wykryto lukę w vllm-project vLLM do wersji 0.26.0. Podatność dotyczy nieznanego kodu w pliku rust/src/parser/src/unified/gemma4.rs komponentu Gemma4UnifiedParser. Wykonanie manipulacji może prowadzić do ataku typu denial of service. Atak może być przeprowadzony zdalnie, a exploit został publicznie ujawniony i może być wykorzystany.

vLLM przed 0.29.0 akceptuje kontrolowane przez użytkownika stop_token_ids w punktach końcowych POST /v1/completions i POST /v1/chat/completions zgodnych z OpenAI, ale waliduje tylko to, że wartości są liczbami całkowitymi, a nie to, czy każdy identyfikator tokenu mieści się w zakresie słownika/modelu logits. Gdy min_tokens > 0, identyfikatory tokenów stop są używane jako indeksy logits do tłumienia tokenów stop, więc identyfikator spoza zakresu trafia do operacji indeksowania CUDA (index_put_) i wywołuje asercję po stronie urządzenia. Uwierzytelniony użytkownik API może wysłać pojedyncze nieprawidłowe żądanie uzupełnienia, które zwraca 500 Internal Server Error i wprowadza EngineCore w stan krytyczny, powodując awarię kolejnych żądań do czasu restartu usługi (odmowa usługi).

W vLLM w wersjach od 0.22.1 do 0.28.0, przypięcie rewizji modelu (--revision / --code-revision) nie jest propagowane do niektórych ładowań artefaktów Hugging Face dla architektur FunAudioChat i Tarsier2. Powoduje to, że wdrożenia przypięte do sprawdzonej rewizji nadal pobierają procesory, tokenizatory i konfiguracje z domyślnej rewizji repozytorium, co może zmienić przetwarzanie audio, zachowanie tokenizatora mowy lub konfigurację Tarsier2 bez zmiany skonfigurowanego przypięcia. Jest to problem integralności łańcucha dostaw i powtarzalności, ale nie stanowi zdalnego wykonania kodu ani obejścia trust_remote_code=False. Problem został naprawiony w wersji 0.28.0.

vLLM w wersjach 0.22.0–0.23.0 nie waliduje stop_token_ids względem zakresu słownika w frontendach Rust HTTP i gRPC, co pozwala identyfikatorom tokenów spoza słownika dotrzeć do MinTokensLogitsProcessor. Atakujący może wysłać żądanie z min_tokens większym od zera i nieprawidłowym stop_token_ids, wywołując błąd indeksowania tensora CUDA i wprowadzając EngineCore w stan krytyczny wymagający restartu usługi.

vLLM przed 0.29.0 nie wymusza walidacji długości promptu dekodera na endpointcie disaggregated serving /inference/v1/generate. Gdy żądanie zawiera ładunek 'features' (multimodalny), token_ids dostarczone przez klienta nie są sprawdzane względem model_config.max_model_len, a dla procesorów multimodalnych ze skip_prompt_length_check=True zbyt długi prompt trafia do bufora wejściowego workera o stałej szerokości max_model_len. Klient mogący dosięgnąć endpointu może wywołać awarię workera i odmowę usługi.

vLLM do 0.29.0 pobiera i w pełni materializuje zdalne lub inline media przed zastosowaniem udokumentowanych ograniczeń (limit rozmiaru skompresowanego audio VLLM_MAX_AUDIO_CLIP_FILESIZE_MB, domyślnie 25 MB, oraz limity --limit-mm-per-prompt). Na czterech ścieżkach wejściowych serwer odczytuje całe ciało odpowiedzi HTTP, dekoduje base64 lub tworzy zadanie pobrania na każdą część mediów, a dopiero potem stosuje limit (lub wcale). Zdalny atakujący może wywołać wyczerpanie pamięci i pasma przed odrzuceniem żądania (denial of service).

vLLM przed wersją 0.29.0 zawiera podatność obejścia limitu zasobów w alokacji dekodera PyNvVideoCodec, gdzie przesłanianie podklasy samplera pozwala na niezależne zwiększanie liczników. Nieuwierzytelnieni atakujący mogą wybierać różne podklasy samplera w żądaniach wideo, aby przekroczyć skonfigurowane limity dekodera i wyczerpać nieewidencjonowaną pamięć GPU.

vLLM przed 0.29.0 nie wymusza limitu VLLM_MAX_AUDIO_CLIP_FILESIZE_MB podczas dekodowania audio w czacie multimodalnym, co pozwala nieuwierzytelnionym klientom obejść ograniczenia rozmiaru pliku. Atakujący mogą przesyłać zbyt duże pliki audio przez endpointy czatu, zużywając nadmierne zasoby pamięci i CPU podczas dekodowania.

vLLM w wersjach przed 0.29.0 zawiera podatność na odmowę usługi w parametrze cache_salt przyjmowanym na endpointach zgodnych z OpenAI i Anthropic API, który nie ma walidacji maksymalnej długości i jest przetwarzany w pojedynczym wątku schedulera EngineCore. Nieuwierzytelnieni atakujący mogą wysyłać żądania HTTP z wartościami salt o rozmiarze setek megabajtów, wywołując kosztowną serializację pickle i hashowanie SHA-256, blokując wątek schedulera i odmawiając usługi wszystkim równoczesnym żądaniom.

vLLM do wersji 0.29.0 nie waliduje parametru tp_size w kv_transfer_params na endpointach ukończeń zgodnych z OpenAI, co pozwala atakującym na alokację nieograniczonej pamięci. Atakujący mogą podawać dowolne wartości tp_size we wdrożeniach z rozdzieleniem prefill/decode, aby wyczerpać pamięć i wywołać zabicie procesu workera decode przez OOM-killer jądra.

vLLM do wersji 0.29.0 zawiera podatność na wyczerpanie zasobów w MooncakeConnector, gdzie odrzucone żądania prefill tworzą placeholdery transferu bez właściciela, które nigdy nie są odzyskiwane. Atakujący mogą wysyłać odrzucone żądania, aby wyczerpać pule zadań sendera, powodując opóźnienia ważnych żądań nawet o 480 sekund, podczas gdy kontrole zdrowotności nadal zwracają sukces.