vLLM vulnerabilities

In vLLM prior to 0.27.0, an integer overflow in blockIdx.x * 2 * d in activation_kernels.cu can cause act_and_mul_kernel to consume another batched user's input, allowing a request processed in the same inference batch to receive a partial or complete copy of another user's inference result. This issue is fixed in version 0.27.0.

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.

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.

vLLM up to and including 0.17.0 allows remote attackers to cause a Denial of Service via memory exhaustion. The AsyncMediaIO.fetch_audio and AsyncMediaIO.fetch_image functions in multimodal/inputs.py fetch user-supplied media URLs using aiohttp and call r.read() without enforcing a maximum response size, allowing an attacker to exhaust server memory by providing a URL to an arbitrarily large file.

vLLM before 0.27.0 fails to properly classify DeepStream as a GPU backend and omits pixel-limit enforcement in its decode path. Unauthenticated attackers can activate DeepStream at request time to initialize the process-wide GPU decode pool and submit video that bypasses resource controls, causing partial denial of service for concurrent requests.

vLLM prior to 0.26.0 in the MiMoV2OmniMultiModalProcessor passes attacker-controlled image and audio strings through _fetch_image, requests.get, and Image.open instead of MediaConnector, bypassing allowed_media_domains and allowed_local_media_path protections. This allows server-side requests and reads of arbitrary files accessible to the vLLM process.

vLLM is an inference and serving engine for large language models. Prior to 0.26.0, the /v1/completions/derender and /v1/chat/completions/derender endpoints accept caller-supplied GenerateResponse objects whose generate_responses, choices, token_ids, prompt_logprobs, logprobs.content, top_logprobs, and routed_experts structures are processed by OnlineDerenderer and tokenizer.decode before max_model_len, max_tokens, max_num_seqs, or response-size limits are enforced, allowing an authenticated API client to consume excessive CPU and memory and produce oversized responses. This issue is fixed in version 0.26.0.

vLLM is an inference and serving engine for large language models. From 0.19.0 until 0.26.0, the prompt field in CompletionRequest in /v1/completions accepts an unbounded list of strings or ints, and functions prompt_to_seq() and OnlineRenderer.preprocess_completion() expand every element, causing the server to create one engine generator and response slot per prompt. An authenticated API client can exhaust CPU, memory, async scheduling capacity, engine request slots, and response buffering with one request. This issue is fixed in version 0.26.0.

In vLLM from 0.20.2rc0 until 0.26.0, safe_load_prompt_embeds in vllm/renderers/embed_utils.py uses torch.sparse.check_sparse_tensor_invariants, whose process-global save, enable, and restore state can be raced by concurrent prompt_embeds parts submitted to POST /v1/chat/completions through AsyncMultiModalItemTracker.resolve_items, asyncio.gather, and the default executor, allowing an invalid sparse tensor to reach tensor.to_dense despite the CVE-2025-62164 guard when enable_prompt_embeds is enabled. This issue is fixed in version 0.26.0.

In vLLM prior to 0.26.0, the structured_outputs.regex parameter in vllm/v1/structured_output/backend_lm_format_enforcer.py is passed to lmformatenforcer.RegexParser without compile_regex_with_timeout or validation in validate_structured_output_request_lm_format_enforcer, allowing an unauthenticated /v1/completions request against the lm-format-enforcer backend to consume a CPU core and stall the structured-output engine path with a catastrophic regular expression. This issue is fixed in version 0.26.0.

In vLLM prior to 0.26.0, the validation_exception_handler in vllm/entrypoints/openai/server_utils.py converts FastAPI RequestValidationError objects with str(exc), and sanitize_message in vllm/entrypoints/utils.py does not remove traceback-style file paths, allowing unauthenticated malformed JSON requests to /v1/chat/completions, /v1/completions, /tokenize, and /detokenize to disclose the OS username, home and virtual-environment paths, Python version, internal package structure, line numbers, and endpoint handler names. This issue is fixed in version 0.26.0.

A vulnerability in the vLLM inference engine before version 0.24.0 allows an attacker to perform a DoS attack by sending a malicious regular expression to the structured_outputs.regex parameter. The expression, lacking compilation timeout and complexity analysis, causes state-space explosion in the grammar compiler, leading to inference worker hang.

A vulnerability in vLLM from version 0.12.0 to before 0.24.0 allows a remote, authorized user to send a /v1/completions request with a model using M-RoPE, causing an assertion failure in EngineCore and a fatal crash of the entire server.

In vLLM before version 0.24.0, a crafted speculative decoding request can cause the rejection sampler to produce a token outside the model vocabulary. This triggers a GPU device-side assertion crash in the engine worker, aborting all concurrent requests.

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.

vLLM is an inference and serving engine for large language models. In versions prior to 0.23.1rc0, temperature validation used comparison operators that incorrectly handled NaN and positive Infinity, leading to undefined behavior or CUDA errors.

vLLM is an inference and serving engine for large language models. Prior to version 0.23.1rc0, the /v1/audio/transcriptions endpoint limits compressed upload size but not decoded PCM output, which could lead to excessive resource consumption.

vLLM, an inference and serving engine for large language models, has a vulnerability due to integer truncation of tensor dimensions, leading to partial tensor processing. As a result, the unfilled portion of the output tensor may contain data from GPU memory, leading to information disclosure.

vLLM is an inference and serving engine for large language models. In versions prior to 0.22.0, revision pinning controls do not consistently apply to all artifacts loaded for a model, potentially leading to the loading of unverified components.

In vLLM prior to 0.22.0, a vulnerability in the activation function loading allows any unauthenticated attacker to achieve arbitrary code execution on the server by publishing a malicious HuggingFace model, when vLLM runs in Python optimized mode (python -O or PYTHONOPTIMIZE=1).

A vulnerability in vLLM versions 0.10.2 through 0.12.9 is due to missing sparse tensor validation in multimodal embeddings processing. An attacker can send crafted requests with malformed tensor indices, causing crashes, resource exhaustion, or potential memory corruption.

A flaw was found in vLLM due to improper handling of image metadata, including EXIF orientation and PNG transparency (tRNS) data. During conversion to RGB, transparency information may be discarded or remapped, causing distortion of input content. This can lead to misinterpretation of images by the model.

vLLM versions 0.8.0 and later are vulnerable to an Out-of-Memory DoS attack due to unbounded frame count processing in the VideoMediaIO.load_base64() method. An attacker can send a single API request with thousands of base64-encoded JPEG frames, causing the server to decode all frames into memory and crash.

A vulnerability was identified in vllm-project vllm version 0.19.0. The issue affects some unknown processing of the OpenAI-compatible Serving Path component. Such manipulation leads to denial of service. The attack can be launched remotely and the exploit is publicly available. The pull request to fix this issue awaits acceptance.

vLLM is an inference and serving engine for large language models. From versions 0.18.0 to before 0.20.0, the extract_hidden_states function in vLLM returns a tensor with an incorrect shape after the first decode step, leading to a RuntimeError and crashing the EngineCore process.

A vulnerability was found in vLLM up to 0.19.0. The affected element is the function has_mamba_layers of the file vllm/v1/kv_cache_interface.py of the component KV Block Handler. Performing a manipulation results in uninitialized resource. It is possible to initiate the attack remotely. The attack is considered to have high complexity. The exploitability is described as difficult. The exploit has been made public and could be used. The existence of this vulnerability is still disputed at present. The proposed patch did not fix the issue. A 3rd party explains: "The divergence could be explained by a benign and expected vLLM behavior where vLLM server could group concurrent requests together resulting in different input shapes based on varying request arrival time. The differences in grouped input shapes could call different kernels with could produce difference results due to rounding and differences in order of operations. There is an environment variable VLLM_BATCH_INVARIANT=1 for users that desire to have deterministic output with temperature 0.0."

A DoS vulnerability in vLLM from version 0.1.0 to before 0.19.0 allows an unauthenticated attacker to block the asyncio event loop and cause Out-Of-Memory crashes by sending a single HTTP request with an astronomically large n parameter in ChatCompletionRequest and CompletionRequest models.

A vulnerability in vLLM from version 0.7.0 to before 0.19.0 allows an attacker to send a single API request with thousands of base64-encoded JPEG frames, causing the server to decode all frames into memory and crash with OOM. The issue is due to missing frame count limit in the VideoMediaIO.load_base64() method.

vLLM from version 0.5.5 to before 0.18.0 defaults to using numpy.mean for mono downmixing (to_mono), while the international standard ITU-R BS.775-4 specifies a weighted downmixing algorithm. This causes inconsistency between audio heard by humans and audio processed by AI models (e.g., via vllm, transformer). This issue is fixed in version 0.18.0.

In vLLM from version 0.10.1 to 0.18.0, two model implementation files hardcode `trust_remote_code=True` when loading sub-components, bypassing the user's explicit `--trust-remote-code=False` security opt-out. This enables remote code execution via malicious model repositories even when the user has explicitly disabled remote code trust.

In vLLM version 0.17.0, the SSRF protection fix for CVE-2026-24779 can be bypassed in the load_from_url_async method due to inconsistent URL parsing between the validation layer and the actual HTTP client. Validation uses urllib3.util.parse_url(), while HTTP requests are made via aiohttp with the yarl library, allowing the bypass.

In vLLM prior to version 0.14.1, an SSRF vulnerability exists in the MediaConnector class. The load_from_url and load_from_url_async methods fetch media from user-supplied URLs, and different parsing libraries interpret backslashes differently, allowing bypass of host restrictions.

A vulnerability in vLLM allows arbitrary Python code execution during model loading if an attacker can influence the model repository path. The issue affects versions 0.10.1 through 0.13.9, where Hugging Face dynamic modules are loaded without trust_remote_code gating.