vLLM vulnerabilities

vLLM through 0.29.0 contains a denial of service vulnerability in P2P KV offloading when OffloadingConnector is configured with TieringOffloadingSpec and a peer-to-peer secondary tier. Attackers can supply arbitrary remote host and port values in kv_transfer_params to create unreachable peer sessions that retain ZeroMQ sockets until the context quota is exhausted, causing an uncaught ZMQError that crashes EngineCore and stops all inference.

vLLM through 0.29.0 contains a denial of service vulnerability in the NIXL connector's prefix caching implementation that fails to properly validate block counts across multi-prompt completion requests in prefill/decode disaggregated deployments. Attackers can trigger an assertion failure in NixlBaseConnectorWorker._apply_prefix_caching by submitting completion requests with multiple prompts of varying lengths, causing the decode worker to terminate and become unavailable until restarted.

vLLM versions through 0.29.0 contain a denial of service vulnerability in the NIXL connector's metadata handling for prefill/decode disaggregated deployments. Attackers can send requests with incomplete kv_transfer_params dictionary entries to trigger an uncaught KeyError in EngineCore scheduling, causing the decode engine to terminate and making all routed requests fail until manual restart.

vLLM through 0.29.0 fails to properly validate bad_words token indices against the model's generation output width in SamplingParams.update_from_tokenizer(). Attackers can supply out-of-bounds token indices that corrupt logits memory of concurrent requests.

vLLM through 0.29.0 contains a memory corruption vulnerability in the Triton _bincount_kernel where prompt token IDs index the penalty prompt-presence bitset without bounds checking against vocabulary size. Attackers can submit multimodal audio requests with tokens equal to vocabulary size, causing out-of-bounds writes that corrupt concurrent requests' sampler state and alter repetition penalty behavior.

vLLM before 0.29.0 validates allowed_token_ids against tokenizer length instead of model output logits width in SamplingParams._validate_allowed_token_ids(). Attackers can supply token IDs above the output vocabulary that pass validation, causing LogitBiasState to corrupt GPU logits state and allow concurrent requests to sample tokens outside their allowlists.

vLLM versions before 0.28.0 fail to validate the lower bound of token IDs in the /v1/embeddings and /pooling endpoints, allowing unauthenticated attackers to crash the engine by submitting negative token IDs. A single request with a negative token ID triggers a CUDA device-side assertion that poisons the GPU context, causing all subsequent requests to fail until the process restarts.

vLLM through 0.29.0 fails to properly clean up decode-side metadata for rejected inference requests in prefill/decode disaggregated deployments. Remote attackers can submit requests with max_tokens=0 to exhaust decode-worker memory without bound until the worker restarts.

Prior to 0.28.0, request bodies for Chat Completions and Responses can set media_io_kwargs.video.video_backend to pynvvideocodec, and MediaConnector.fetch_video forwards that choice to VideoMediaIO even when startup configuration selected a software decoder. The engine's _reserve_mm_ipc_gpu_memory logic budgets decoder memory only from static configuration, so the request-selected VIDEO_LOADER_REGISTRY backend can create a CUDA context, decoder surfaces, and decoded-frame allocations that were not removed from the engine's KV-cache budget.

vLLM before version 0.24.0 in the input_audio handling path for /v1/chat/completions does not pass VLLM_MAX_AUDIO_DECODE_DURATION_S to the shared audio decoder. An unauthenticated client can submit a small compressed audio input that expands into a very large float32 PCM allocation, bypassing the duration guard and causing an out-of-memory worker crash.

A vulnerability was found in vllm-project vllm up to 0.29.0. Affected by this issue is some unknown functionality of the file vllm/v1/sample/thinking_budget_state.py. The manipulation results in inefficient algorithmic complexity, and the attack can be launched remotely.

A vulnerability was found in vLLM versions 0.26.0 and 0.27.0 within the MoRIIO Acknowledgement Handler component. Manipulation of the request_id/kv_transfer_params arguments in MoRIIOConnectorScheduler.request_finished, MoRIIOConnectorWorker.get_finished, and MoRIIOWrapper._handle_release_message leads to resource consumption. The attack can be initiated remotely, and the project has not yet reacted to the report.

In vLLM up to 0.29.0, a vulnerability in the TiktokenTokenizer::new function (rust/src/text/src/backend/hf/mod.rs) leads to DoS via local manipulation.

vLLM versions before 0.28.0 fail to validate audio sample rate headers in the transcription endpoint, allowing authenticated clients to bypass duration checks. Attackers can submit forged FLAC headers with inflated sample rates to trigger excessive memory allocation and crash the API server process affecting all tenants.

vLLM versions >=0.10.2 and <0.28.0 do not apply any audio decode-size or duration limit when extracting audio from video input for NanoNemotronVL models. In nano_nemotron_vl.py, _extract_audio_from_videos calls load_audio_pyav(BytesIO(video_bytes)) without the max_duration_s or max_decode_bytes parameters, so neither VLLM_MAX_AUDIO_DECODE_DURATION_S nor VLLM_MAX_AUDIO_DECODE_BYTES is enforced (unlike the direct audio upload path in AudioMediaIO). When a NanoNemotronVL model is served with use_audio_in_video=True, an attacker who supplies a small, highly compressed video as multimodal input can force the server to allocate gigabytes of memory during audio decoding, resulting in a denial of service. Fixed in vLLM 0.28.0.

vLLM before 0.28.0 contains a remote code execution vulnerability in the LlavaOnevision2 processor loader that ignores the trust_remote_code parameter when loading remote processor classes. Attackers can craft a malicious model with arbitrary code in processing_llava_onevision2.py that executes with vLLM process authority even when trust_remote_code is set to False.

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

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.

vLLM, an inference and serving engine for large language models, prior to 0.11.1 has a critical remote code execution vector in the Nemotron_Nano_VL_Config config class. Loading a model config with an auto_map entry fetches and executes Python from a remote repository, even when trust_remote_code=False is set.

vLLM is an inference and serving engine for large language models (LLMs). From version 0.5.5 to before 0.11.1, the /v1/chat/completions and /tokenize endpoints allow a chat_template_kwargs request parameter that is used in the code before proper validation against the chat template. With the right chat_template_kwargs parameters, it is possible to block processing of the API server for long periods, delaying all other requests. This issue is patched in version 0.11.1.

vLLM, an inference engine for large language models, in versions 0.5.5 to before 0.11.1 allows users to crash the engine serving multimodal models by passing embedding inputs with correct ndim but incorrect shape. This is patched in version 0.11.1.