CVE-2026-55646
MediumCVSS 6.5Exploitation Probability (EPSS)
Low risk44th percentile - higher than 44% of all known CVEs
Summary
A vulnerability in vLLM versions 0.22.0 to 0.23.0 allows an attacker to upload oversized audio files via the /v1/audio/transcriptions or /v1/audio/translations API. The file is read into memory before the size limit is checked, potentially causing memory exhaustion or process termination.
Risk Assessment
The organization is exposed to a DoS (Denial of Service) attack where a large audio file can exhaust server memory and crash vLLM, impacting service availability.
Recommendation
Upgrade vLLM to version 0.24.0 or later immediately, which fixes the issue by checking the file size limit before reading the file into memory.
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.22.0 to 0.23.0, the /v1/audio/transcriptions and /v1/audio/translations routes call request.file.read() to fully materialize an uploaded audio file into memory before vLLM checks the documented VLLM_MAX_AUDIO_CLIP_FILESIZE_MB compressed upload size limit (default 25 MB) later in the speech-to-text preprocessing step, so an API caller who can reach those routes can submit an oversized multipart upload and cause vLLM to allocate memory proportional to the uploaded file size before the request is rejected as too large, creating memory pressure or terminating the process depending on deployment resource limits. This issue is fixed in version 0.24.0.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

