Podatności vLLM

W vLLM przed wersją 0.28.0 treści żądań dla Chat Completions i Responses mogą ustawić media_io_kwargs.video.video_backend na pynvvideocodec, a MediaConnector.fetch_video przekazuje ten wybór do VideoMediaIO, nawet gdy konfiguracja startowa wybrała dekoder programowy. Logika _reserve_mm_ipc_gpu_memory budżetuje pamięć dekodera tylko na podstawie statycznej konfiguracji, więc backend VIDEO_LOADER_REGISTRY wybrany przez żądanie może utworzyć kontekst CUDA, powierzchnie dekodera i alokacje ramek, które nie zostały usunięte z budżetu KV-cache.

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 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.

vLLM do wersji 0.29.0 zawiera podatność na odmowę usługi w P2P KV offloading, gdy OffloadingConnector jest skonfigurowany z TieringOffloadingSpec i drugorzędnym poziomem peer-to-peer. Atakujący mogą podawać dowolne wartości zdalnego hosta i portu w kv_transfer_params, tworząc nieosiągalne sesje peer, które utrzymują gniazda ZeroMQ do wyczerpania limitu kontekstu, powodując nieprzechwycony ZMQError, który zawiesza EngineCore i zatrzymuje całe wnioskowanie.

vLLM do wersji 0.29.0 zawiera podatność na odmowę usługi w implementacji prefiksowego buforowania w łączniku NIXL, która nieprawidłowo waliduje liczbę bloków w żądaniach z wieloma promptami w środowiskach z rozdzielonym prefill/decode. Atakujący może wywołać błąd asercji w NixlBaseConnectorWorker._apply_prefix_caching, wysyłając żądania z wieloma promptami o różnej długości, co powoduje zatrzymanie workera dekodującego i jego niedostępność do czasu restartu.

vLLM do wersji 0.29.0 zawiera podatność na odmowę usługi w obsłudze metadanych łącznika NIXL w środowiskach z rozdzielonym prefill/decode. Atakujący może wysyłać żądania z niekompletnymi wpisami w słowniku kv_transfer_params, aby wywołać nieobsłużony wyjątek KeyError w harmonogramie EngineCore, co powoduje zatrzymanie silnika dekodującego i awarię wszystkich routowanych żądań do czasu ręcznego restartu.

vLLM do wersji 0.29.0 nieprawidłowo waliduje indeksy tokenów bad_words względem szerokości wyjścia generacji modelu w funkcji SamplingParams.update_from_tokenizer(). Atakujący może dostarczyć indeksy tokenów poza zakresem, które uszkadzają pamięć logits równoległych żądań.

vLLM do wersji 0.29.0 zawiera podatność na uszkodzenie pamięci w jądrze Triton _bincount_kernel, gdzie identyfikatory tokenów promptu indeksują zestaw bitów obecności tokenów bez sprawdzania granic względem rozmiaru słownika. Atakujący może wysłać multimodalne żądania audio z tokenami równymi rozmiarowi słownika, co powoduje zapisy poza zakresem, które uszkadzają stan próbkowania współbieżnych żądań i zmieniają zachowanie kary za powtórzenia.

vLLM przed wersją 0.29.0 waliduje allowed_token_ids względem długości tokenizera zamiast szerokości logitów wyjściowych modelu w metodzie SamplingParams._validate_allowed_token_ids(). Atakujący może podać identyfikatory tokenów powyżej słownika wyjściowego, które przechodzą walidację, co powoduje uszkodzenie stanu logitów GPU i pozwala współbieżnym żądaniom na próbkowanie tokenów spoza ich list dozwolonych.

vLLM w wersjach przed 0.28.0 nie waliduje dolnej granicy identyfikatorów tokenów w endpointach /v1/embeddings i /pooling, co pozwala nieuwierzytelnionym atakującym na zawieszenie silnika poprzez przesłanie ujemnych identyfikatorów tokenów. Pojedyncze żądanie z ujemnym identyfikatorem tokenu wywołuje asercję po stronie urządzenia CUDA, która zatruwa kontekst GPU, powodując awarię wszystkich kolejnych żądań aż do restartu procesu.

vLLM do wersji 0.29.0 nie czyści poprawnie metadanych po stronie dekodowania dla odrzuconych żądań wnioskowania w środowiskach z rozdzielonym prefill/decode. Zdalny atakujący może wysyłać żądania z max_tokens=0, aby wyczerpać pamięć workerów dekodujących bez ograniczeń, aż do ich restartu.

vLLM przed wersją 0.24.0 w ścieżce obsługi input_audio dla /v1/chat/completions nie przekazuje limitu VLLM_MAX_AUDIO_DECODE_DURATION_S do wspólnego dekodera audio. Nieuwierzytelniony klient może przesłać mały skompresowany plik audio, który rozszerza się do bardzo dużej alokacji PCM float32, omijając zabezpieczenie czasu trwania i powodując awarię procesu roboczego z powodu wyczerpania pamięci.

W vllm-project vllm do wersji 0.29.0 występuje podatność w nieznanej funkcjonalności pliku vllm/v1/sample/thinking_budget_state.py. Manipulacja prowadzi do nieefektywnej złożoności algorytmicznej, a atak można przeprowadzić zdalnie.

W vLLM w wersjach 0.26.0 i 0.27.0 wykryto podatność w komponencie MoRIIO Acknowledgement Handler. Manipulacja argumentami request_id/kv_transfer_params w funkcjach MoRIIOConnectorScheduler.request_finished, MoRIIOConnectorWorker.get_finished oraz MoRIIOWrapper._handle_release_message prowadzi do nadmiernego zużycia zasobów. Atak można przeprowadzić zdalnie, a projekt nie zareagował jeszcze na zgłoszenie.

W projekcie vLLM do wersji 0.29.0 wykryto podatność w funkcji TiktokenTokenizer::new (plik rust/src/text/src/backend/hf/mod.rs) prowadzącą do ataku DoS przez lokalne manipulacje.

vLLM w wersjach przed 0.28.0 nie waliduje nagłówków częstotliwości próbkowania audio w punkcie końcowym transkrypcji, co pozwala uwierzytelnionym klientom obejść kontrole czasu trwania. Atakujący mogą przesłać sfałszowane nagłówki FLAC ze zawyżoną częstotliwością próbkowania, aby wywołać nadmierną alokację pamięci i awarię procesu serwera API, dotykając wszystkich dzierżawców.

vLLM w wersjach >=0.10.2 i <0.28.0 nie stosuje żadnego limitu rozmiaru dekodowania audio ani czasu trwania przy wyodrębnianiu audio z wejścia wideo dla modeli NanoNemotronVL. W pliku nano_nemotron_vl.py funkcja _extract_audio_from_videos wywołuje load_audio_pyav(BytesIO(video_bytes)) bez parametrów max_duration_s lub max_decode_bytes, więc ani VLLM_MAX_AUDIO_DECODE_DURATION_S, ani VLLM_MAX_AUDIO_DECODE_BYTES nie są egzekwowane (w przeciwieństwie do bezpośredniej ścieżki przesyłania audio w AudioMediaIO). Gdy model NanoNemotronVL jest obsługiwany z use_audio_in_video=True, atakujący dostarczający mały, silnie skompresowany film jako wejście multimodalne może zmusić serwer do alokacji gigabajtów pamięci podczas dekodowania audio, powodując odmowę usługi. Naprawiono w vLLM 0.28.0.

vLLM w wersjach przed 0.28.0 zawiera podatność zdalnego wykonania kodu w loaderze procesora LlavaOnevision2, który ignoruje parametr trust_remote_code przy ładowaniu zdalnych klas procesora. Atakujący może przygotować złośliwy model z dowolnym kodem w pliku processing_llava_onevision2.py, który zostanie wykonany z uprawnieniami procesu vLLM, nawet gdy trust_remote_code ma wartość False.

vLLM do wersji 0.17.0 włącznie pozwala zdalnym atakującym na spowodowanie odmowy usługi (DoS) poprzez wyczerpanie pamięci. Funkcje AsyncMediaIO.fetch_audio i AsyncMediaIO.fetch_image w multimodal/inputs.py pobierają adresy URL mediów dostarczone przez użytkownika za pomocą aiohttp i wywołują r.read() bez narzucania maksymalnego rozmiaru odpowiedzi, co pozwala atakującemu wyczerpać pamięć serwera, podając URL do dowolnie dużego pliku.

vLLM przed wersją 0.27.0 nieprawidłowo klasyfikuje DeepStream jako backend GPU i pomija egzekwowanie limitów pikseli w ścieżce dekodowania. Nieuwierzytelnieni atakujący mogą aktywować DeepStream w czasie żądania, inicjalizując procesowy pulę GPU do dekodowania i przesyłając wideo, które omija kontrolę zasobów, powodując częściową odmowę usługi dla równoczesnych żądań.

vLLM przed wersją 0.26.0 w procesorze MiMoV2OmniMultiModalProcessor przekazuje kontrolowane przez atakującego ciągi obrazów i audio przez _fetch_image, requests.get i Image.open zamiast MediaConnector, omijając ochronę allowed_media_domains i allowed_local_media_path. Umożliwia to żądania po stronie serwera i odczyt dowolnych plików dostępnych dla procesu vLLM.

vLLM to silnik wnioskowania i serwowania dla dużych modeli językowych. Przed wersją 0.26.0, endpointy /v1/completions/derender i /v1/chat/completions/derender akceptują obiekty GenerateResponse dostarczone przez wywołującego, których struktury generate_responses, choices, token_ids, prompt_logprobs, logprobs.content, top_logprobs i routed_experts są przetwarzane przez OnlineDerenderer i tokenizer.decode przed egzekwowaniem limitów max_model_len, max_tokens, max_num_seqs lub rozmiaru odpowiedzi, co pozwala uwierzytelnionemu klientowi API na zużycie nadmiernej ilości CPU i pamięci oraz generowanie zbyt dużych odpowiedzi. Problem naprawiono w wersji 0.26.0.

vLLM to silnik wnioskowania i serwowania dla dużych modeli językowych. Od wersji 0.19.0 do 0.26.0 pole prompt w CompletionRequest w /v1/completions akceptuje nieograniczoną listę stringów lub list intów, a funkcje prompt_to_seq() i OnlineRenderer.preprocess_completion() rozwijają każdy element, co powoduje, że serwer tworzy osobny generator i slot odpowiedzi dla każdego promptu. Uwierzytelniony klient API może wyczerpać CPU, pamięć, zdolności planowania asynchronicznego, sloty żądań silnika i buforowanie odpowiedzi jednym żądaniem. Problem naprawiono w wersji 0.26.0.

W vLLM przed wersją 0.27.0 występuje przepełnienie liczby całkowitej w wyrażeniu blockIdx.x * 2 * d w activation_kernels.cu, co może spowodować, że kernel act_and_mul_kernel zużyje dane wejściowe innego użytkownika w tej samej partii, umożliwiając żądaniu przetwarzanemu w tej samej partii wnioskowania otrzymanie częściowej lub pełnej kopii wyniku wnioskowania innego użytkownika. Problem naprawiono w wersji 0.27.0.

W vLLM od wersji 0.20.2rc0 do 0.26.0 funkcja safe_load_prompt_embeds w vllm/renderers/embed_utils.py używa torch.sparse.check_sparse_tensor_invariants, którego globalny stan zapisu, włączenia i przywracania może być wyścigowany przez równoczesne części prompt_embeds przesyłane do POST /v1/chat/completions przez AsyncMultiModalItemTracker.resolve_items, asyncio.gather i domyślny executor, co pozwala na dotarcie nieprawidłowego rzadkiego tensora do tensor.to_dense pomimo zabezpieczenia CVE-2025-62164, gdy włączona jest opcja enable_prompt_embeds. Problem naprawiono w wersji 0.26.0.

W vLLM przed wersją 0.26.0 parametr structured_outputs.regex w vllm/v1/structured_output/backend_lm_format_enforcer.py jest przekazywany do lmformatenforcer.RegexParser bez compile_regex_with_timeout lub walidacji w validate_structured_output_request_lm_format_enforcer, co pozwala nieuwierzytelnionemu żądaniu /v1/completions przeciwko backendowi lm-format-enforcer na zużycie rdzenia CPU i zablokowanie ścieżki silnika strukturalnego wyjścia za pomocą katastrofalnego wyrażenia regularnego. Problem naprawiono w wersji 0.26.0.

W vLLM przed wersją 0.26.0 funkcja validation_exception_handler w vllm/entrypoints/openai/server_utils.py konwertuje obiekty FastAPI RequestValidationError za pomocą str(exc), a sanitize_message w vllm/entrypoints/utils.py nie usuwa ścieżek plików w stylu traceback, co pozwala nieuwierzytelnionym żądaniom z nieprawidłowym JSON do /v1/chat/completions, /v1/completions, /tokenize i /detokenize na ujawnienie nazwy użytkownika systemu, ścieżek domowych i środowisk wirtualnych, wersji Pythona, wewnętrznej struktury pakietów, numerów linii i nazw handlerów endpointów. Problem naprawiono w wersji 0.26.0.

Podatność w silniku wnioskowania vLLM przed wersją 0.24.0 pozwala atakującemu na wykonanie ataku DoS poprzez przesłanie złośliwego wyrażenia regularnego do parametru structured_outputs.regex. Wyrażenie to, pozbawione limitu czasu kompilacji i analizy złożoności, powoduje eksplozję stanów w kompilatorze gramatyki, co prowadzi do zawieszenia procesu wnioskowania.

Podatność w bibliotece vLLM od wersji 0.12.0 do 0.24.0 pozwala zdalnemu, autoryzowanemu użytkownikowi na wysłanie żądania /v1/completions z modelem używającym M-RoPE, co powoduje błąd asercji w EngineCore i awarię całego serwera.

W silniku vLLM przed wersją 0.24.0 wykryto podatność polegającą na tym, że specjalnie spreparowane żądanie spekulatywnego dekodowania może spowodować wygenerowanie tokena spoza słownika modelu. Prowadzi to do awarii procesu roboczego (worker) z powodu asercji na GPU, co skutkuje przerwaniem wszystkich współbieżnych żądań.

Podatność w vLLM od wersji 0.22.0 do 0.23.0 pozwala atakującemu na przesłanie zbyt dużego pliku audio przez API /v1/audio/transcriptions lub /v1/audio/translations. Plik jest wczytywany do pamięci przed sprawdzeniem limitu rozmiaru, co może prowadzić do wyczerpania pamięci lub awarii procesu.

vLLM to silnik wnioskowania i serwowania dla dużych modeli językowych. W wersjach przed 0.23.1rc0, walidacja temperatury używała operatorów porównania, które nieprawidłowo obsługiwały wartości NaN i dodatnią nieskończoność, co prowadziło do nieokreślonego zachowania lub błędów CUDA.

vLLM to silnik inferencji i serwowania dużych modeli językowych. W wersjach przed 0.23.1rc0, punkt końcowy /v1/audio/transcriptions ograniczał rozmiar przesyłanych plików skompresowanych, ale nie dekodowanych danych PCM, co mogło prowadzić do nadmiernego zużycia zasobów.

vLLM, silnik do wnioskowania i serwowania dużych modeli językowych, ma podatność na truncację liczb całkowitych w wymiarach tensorów, co prowadzi do częściowego przetwarzania tensorów. W wyniku tego, niepełna część tensoru wyjściowego może zawierać dane z pamięci GPU, co prowadzi do ujawnienia informacji.

vLLM to silnik inferencji i serwowania dużych modeli językowych. W wersjach przed 0.22.0, kontrola wersji nie stosuje się konsekwentnie do wszystkich artefaktów ładowanych dla modelu, co może prowadzić do ładowania niezweryfikowanych komponentów.

W vLLM przed wersją 0.22.0 wykryto podatność polegającą na braku odpowiedniego zabezpieczenia w funkcji ładującej aktywacje. Umożliwia ona nieuwierzytelnionemu atakującemu zdalne wykonanie dowolnego kodu na serwerze poprzez opublikowanie złośliwego modelu na HuggingFace, gdy vLLM działa w zoptymalizowanym trybie Pythona (python -O lub PYTHONOPTIMIZE=1).

Podatność w vLLM w wersjach od 0.10.2 do 0.12.9 wynika z braku walidacji rzadkich tensorów podczas przetwarzania osadzeń multimodalnych. Atakujący może wysłać spreparowane żądania z nieprawidłowymi indeksami tensorów, powodując awarię, wyczerpanie zasobów lub potencjalne uszkodzenie pamięci.

W bibliotece vLLM wykryto podatność związaną z nieprawidłowym przetwarzaniem metadanych obrazów, takich jak orientacja EXIF i przezroczystość PNG (tRNS). Podczas konwersji obrazów do RGB informacje o przezroczystości są pomijane lub mapowane w nieoczekiwany sposób, co prowadzi do zniekształcenia treści wejściowej. Może to spowodować błędną interpretację obrazu przez model.

vLLM w wersjach 0.8.0 i nowszych jest podatny na atak DoS przez wyczerpanie pamięci w metodzie VideoMediaIO.load_base64() z powodu nieograniczonego przetwarzania liczby klatek. Atakujący może wysłać pojedyncze żądanie API zawierające tysiące zakodowanych w base64 klatek JPEG, powodując dekodowanie wszystkich klatek do pamięci i awarię serwera.

W projekcie vllm-project vllm w wersji 0.19.0 stwierdzono podatność na atak DoS w komponencie OpenAI-compatible Serving Path. Manipulacja prowadzi do odmowy usługi. Atak może być przeprowadzony zdalnie, a exploit jest publicznie dostępny. Pull request z poprawką oczekuje na akceptację.

vLLM to silnik inferencji i serwowania dużych modeli językowych. W wersjach od 0.18.0 do przed 0.20.0, funkcja extract_hidden_states w vLLM zwraca tensor o nieprawidłowym kształcie po pierwszym kroku dekodowania, co prowadzi do błędu RuntimeError i awarii procesu EngineCore.

Podatność znaleziona w vLLM do wersji 0.19.0. Dotyczy funkcji has_mamba_layers w pliku vllm/v1/kv_cache_interface.py komponentu KV Block Handler. Manipulacja prowadzi do użycia niezainicjalizowanego zasobu. Atak może być przeprowadzony zdalnie, ale ma wysoką złożoność i jest trudny do wykorzystania. Exploit został opublikowany, ale istnienie podatności jest kwestionowane. Proponowana poprawka nie rozwiązała problemu. Strona trzecia wyjaśnia, że rozbieżność może wynikać z normalnego zachowania vLLM, gdzie serwer grupuje równoczesne żądania, co prowadzi do różnych kształtów wejścia. Istnieje zmienna środowiskowa VLLM_BATCH_INVARIANT=1 dla użytkowników pragnących deterministycznego wyniku przy temperaturze 0.0.

Podatność DoS w vLLM od wersji 0.1.0 do 0.19.0 pozwala nieuwierzytelnionemu atakującemu na zablokowanie pętli zdarzeń asyncio i wywołanie awarii Out-Of-Memory poprzez wysłanie pojedynczego żądania HTTP z bardzo dużą wartością parametru n w modelach ChatCompletionRequest i CompletionRequest.

Podatność w vLLM od wersji 0.7.0 do 0.19.0 pozwala atakującemu na wysłanie pojedynczego żądania API z tysiącami zakodowanych w base64 ramek JPEG, co powoduje dekodowanie wszystkich ramek do pamięci i awarię serwera z powodu braku pamięci (OOM). Problem wynika z braku ograniczenia liczby ramek w metodzie VideoMediaIO.load_base64().

vLLM od wersji 0.5.5 do przed 0.18.0 używa domyślnie numpy.mean do downmixu mono (to_mono), podczas gdy międzynarodowy standard ITU-R BS.775-4 określa ważony algorytm downmixu. Powoduje to niezgodność między dźwiękiem słyszanym przez ludzi a dźwiękiem przetwarzanym przez modele AI (np. przez vllm, transformer). Luka została naprawiona w wersji 0.18.0.

W vLLM od wersji 0.10.1 do 0.18.0 dwa pliki implementacji modeli na stałe ustawiają `trust_remote_code=True` podczas ładowania podkomponentów, ignorując jawne ustawienie użytkownika `--trust-remote-code=False`. Umożliwia to zdalne wykonanie kodu przez złośliwe repozytoria modeli, nawet gdy użytkownik wyraźnie wyłączył zaufanie do zdalnego kodu.

W vLLM w wersji 0.17.0 obejście zabezpieczenia SSRF dodanego w CVE-2026-24779 jest możliwe w metodzie load_from_url_async z powodu niespójności w parsowaniu URL-i między warstwą walidacji a rzeczywistym klientem HTTP. Walidacja używa urllib3.util.parse_url(), podczas gdy zapytania HTTP wykonuje aiohttp z biblioteką yarl, co pozwala na ominięcie ochrony.

W projekcie vLLM przed wersją 0.14.1 wykryto podatność SSRF w klasie MediaConnector. Metody load_from_url i load_from_url_async pobierają multimedia z adresów URL podanych przez użytkownika, a różne biblioteki parsujące różnie interpretują ukośniki odwrotne, co pozwala ominąć ograniczenia hosta docelowego.