CVE-2026-94622

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