vLLM versions prior to 0.32.0 have a permissive default CORS configuration allowing any origin to send cross-origin requests to the HTTP server. Without an API key configured, no authentication is enforced, enabling malicious web pages to access and interact with the server if reachable by the victim's browser. This can lead to unauthorized enumeration of models and execution of chat completions, potentially consuming GPU resources and exposing model outputs. The issue is fixed in version 0.32.0.
vLLM deployments serving DeepSeek-OCR family models are vulnerable to a denial of service caused by a crafted PNG image. A legitimate half-black/half-white 1024×1024 image triggers a zero-sum pixel value condition that causes the model's input validation to return None. This leads to an assertion failure in the engine worker process, crashing the entire service and requiring manual restart. The issue affects versions from 0.11.1 up to but not including 0.32.0 and is fixed in version 0.32.0.
vLLM versions prior to 0.32.0 contain a vulnerability where an out-of-vocabulary token ID equal to the vocabulary size can bypass input validation and cause a CUDA device-side assert, crashing the engine. This affects models whose vocabulary size is an exact multiple of the embedding padding size (64), such as Llama-2-family models with a vocab size of 32000. The issue occurs specifically when using a single GPU (tensor parallel size 1) configuration. The flaw was fixed in vLLM version 0.32.0 by correcting the maximum accepted token ID validation.
vLLM versions 0.19.0 through 0.31.x have a denial-of-service vulnerability in their chat template rendering. The issue arises because the Jinja2 rendering in a sandboxed environment lacks execution timeouts and output limits, and runs in a single-threaded pool that cannot be interrupted. An authenticated attacker can submit a crafted template that exhausts the renderer thread pool or causes out-of-memory conditions, permanently denying chat-style API endpoints until the process is restarted. This affects all tenants on the same API-server replica and can also be triggered by malicious model repositories with hostile templates. The vulnerability is fixed in version 0.32.0.
vLLM versions from 0.7.3 up to but not including 0.31.0 have a vulnerability where an attacker can control the mm_processor_kwargs.code_revision parameter in multimodal requests. When the operator enables trust_remote_code and serves a model whose Hugging Face processor uses dynamic auto_map code, this allows the attacker to execute arbitrary Python code by importing a malicious processor module revision. The vulnerability is exploitable via unauthenticated /tokenize endpoints unless protected externally. A fix is available in vLLM version 0.31.0.
vLLM versions prior to 0.32.0 contain a resource exhaustion vulnerability in the P2P secondary tier management. An API client can submit many unique peer addresses that never establish connections, causing vLLM to retain sessions and ZeroMQ sockets indefinitely. This leads to exhaustion of the ZeroMQ context socket quota, raising a ZMQError that terminates the EngineCore and shuts down the API server. The vulnerability allows denial of service without requiring privileged access or internal listener connectivity. A fix is available in vLLM 0.32.0.
vLLM versions from 0.16.0 up to but not including 0.32.0 contain a vulnerability in the /v1/responses endpoint that allows an authenticated user to supply a malicious template in chat_template_kwargs[chat_template]. This bypasses the intended trust policy and can lead to uncontrolled CPU or memory consumption during Jinja template rendering. The issue is resolved in version 0.32.0.
vLLM is an inference and serving engine for large language models. Prior to 0.32.0, 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 therefore 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 environments using Pillow 12.0.0 through 12.2.0 can trigger CVE-2026-59203 and exhaust media-loading workers. Deployments without the applicable vulnerable dependency are not affected by that corresponding impact. This issue is fixed in version 0.32.0.
vLLM versions prior to 0.32.0 contain a resource allocation vulnerability in the Phi-4 multimodal audio encoder. The default use of eager attention causes large attention matrices to be fully materialized in GPU memory when processing long audio clips. This results in quadratic GPU memory consumption, potentially leading to out-of-memory conditions that terminate the EngineCore process for all users. The issue is resolved in version 0.32.0.
vLLM is an inference and serving engine for large language models. Prior to 0.32.0, an authenticated caller 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. This issue is fixed in version 0.32.0.