Podatności vLLM

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.

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

Podatność w vLLM umożliwia wykonanie dowolnego kodu Pythona podczas ładowania modelu, jeśli atakujący ma wpływ na ścieżkę repozytorium modelu. Problem występuje w wersjach od 0.10.1 do 0.13.9, gdzie moduły dynamiczne Hugging Face są ładowane bez weryfikacji trust_remote_code.