CVE-2026-115918

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