CVE-2026-105758
MediumCVSS 5.3Exploitation Probability (EPSS)
Low risk21th percentile - higher than 21% of all known CVEs
Summary
In vLLM from 0.24.0 to 0.30.0, the Qwen2VLVideoBackend and Qwen3VLVideoBackend classes accept request-level values for max_frames and fps without server-side ceilings, allowing an unauthenticated caller to decode every frame from attacker-controlled video and consume disproportionate memory.
Risk Assessment
An attacker can submit requests to /tokenize with large values, causing excessive frame decoding, memory consumption, and potential API process termination before scheduling.
Recommendation
Upgrade vLLM to version 0.30.0 or later, which includes a fix.
Other vulnerabilities in vLLM
See all- CVE-2026-48746Critical
Vulnerability in vLLM versions 0.3.0 to 0.22.0 allows bypass of OpenAI API AuthenticationMiddleware. An attacker can use the API without providing the configured VLLM_API_KEY or --api-key.
- CVE-2026-22778Critical
A vulnerability in vLLM from version 0.8.3 to 0.14.0 leaks a heap address when an invalid image is sent to the multimodal endpoint. This leak reduces ASLR effectiveness from 4 billion to about 8 guesses, facilitating further attacks.
- CVE-2026-115918Medium
vLLM from 0.16.0 until 0.32.0 allows an authenticated caller to place an attacker-controlled template in chat_template_kwargs[chat_template] when no server template is configured. ChatParams.get_apply_chat_template_kwargs() preserves that value without enforcing trust_request_chat_template, bypassing the trust policy and causing CPU or memory exhaustion through Jinja rendering.
- CVE-2026-115917Low
vLLM is an inference and serving engine for large language models. Prior to 0.32.0, the OpenAI-compatible server configures Starlette CORSMiddleware with allowed_origins set to a wildcard by default. A malicious web page can use a victim's browser to reach an unauthenticated vLLM server on localhost, an internal network, or a VPN, call endpoints including GET /v1/models and POST /v1/chat/completions, consume GPU resources, and read responses. This issue is fixed in version 0.32.0.
- CVE-2026-115916Medium
vLLM before 0.32.0, in vllm/tokenizers/hf.py, computes max_token_id with an off-by-one upper bound, allowing a pre-tokenized prompt ID equal to the vocabulary size to pass validation. For tensor-parallel size one and an exact multiple-of-64 vocabulary, VocabParallelEmbedding.forward does not mask that value before F.embedding uses it, causing a CUDA device-side assertion and terminating the engine.
- CVE-2026-115915High
Prior to 0.32.0, vLLM's ImageMediaIO passes attacker-controlled image bytes to Pillow through Image.open(BytesIO(data)) without restricting decoder selection, and the MIME label does not constrain the selected format. Image-capable request paths through parse_image() and fetch_image() can dispatch an EPS payload to host components; a host with Ghostscript affected by CVE-2024-29510 can execute commands with the vLLM process's privileges, while Pillow 12.0.0 through 12.2.0 can trigger CVE-2026-59203 and exhaust media-loading workers.
- CVE-2026-115914Medium
vLLM from 0.11.1 until 0.32.0, in the DeepSeek-OCR, DeepSeek-OCR-2, and Unlimited-OCR image path, allows a remote client reaching the OpenAI-compatible API to submit a legal image whose normalized pixels sum to zero when alone in its per-step encoder batch. _parse_and_validate_image_input returns no embedding, embed_multimodal propagates that value, and sanity_check_mm_encoder_outputs triggers a fatal assertion that shuts down the engine for all users.
- CVE-2026-115913Medium
vLLM is an inference and serving engine for large language models. Prior to 0.32.0, the Phi-4 multimodal audio encoder in phi4mm_audio.py and phi4mm_utils.py uses eager attention by default, allowing a remote client to submit one long audio clip that materializes full attention matrices and causes quadratic GPU-memory use, leading to out-of-memory and termination of EngineCore for all users.
- CVE-2026-115912High
Prior to 0.32.0, an authenticated caller in vLLM can place forged shared-memory address and monotonic_id values in public multimodal features.kwargs_data. In scale-out deployments with shared-memory multimodal caching enabled, workers trust those values and pass attacker-selected bytes to pickle.loads(), allowing arbitrary Python execution even when insecure serialization is disabled.
- CVE-2026-115911Medium
vLLM is an inference and serving engine for large language models. From 0.19.0 until 0.32.0, authenticated callers can supply a chat template when no server-side --chat-template is configured, or a malicious model repository can provide a template compiled and rendered by tokenizer.apply_chat_template() without a wall-clock timeout, output-size limit, or iteration bound. Rendering runs in a ThreadPoolExecutor with one worker, so a nonterminating render can block /v1/responses and other chat-template users, while an output-expanding render can exhaust server memory.
Original NVD description (English source)
vLLM is an inference and serving engine for large language models. From 0.24.0 until 0.30.0, the Qwen2VLVideoBackend and Qwen3VLVideoBackend classes accept request-level values for the media_io_kwargs.video.max_frames and media_io_kwargs.video.fps fields without enforcing server-side ceilings. An unauthenticated caller can submit these values to the /tokenize endpoint, causing the sampler to decode every frame selected from attacker-controlled video input, consume disproportionate frontend memory, and potentially terminate the API process before scheduling or admission control. The Rust frontend is not affected because it rejects the media_io_kwargs field. This issue is fixed in version 0.30.0.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

