CVE-2026-100647

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.

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.