vLLM versions prior to 0.31.0 contain a vulnerability where the min_tokens <= max_tokens validation is skipped if max_tokens is null in /inference/v1/generate requests. This leads to an uncaught exception that causes the EngineCore input thread to die, hanging all subsequent generation requests until the service is manually restarted. The vulnerability allows unauthenticated remote attackers to disrupt service availability by sending a single crafted request.
vLLM before 0.31.0 uses a client-supplied multimodal uuid verbatim as cache identity with no consistency check on cache hits, allowing engine crashes. Unauthenticated attackers can desynchronize the P0/P1 processor caches to trigger a fatal token-placeholder mismatch, killing the entire serving instance until restarted.
vLLM versions before 0.31.0 have a vulnerability in the InputBatch.condense() function that causes a cross-request mask leak. This flaw allows remote attackers to influence other clients' output generation by leaving stale allowed_token_ids rows, effectively constraining victims' token outputs. The vulnerability can be exploited via concurrent constrained generate requests, including unauthenticated /invocations, leading to token allowlist reuse across batch slots.
A security flaw has been discovered in vllm-project vLLM up to 0.31.0. This impacts the function get_token_bin_counts_and_mask of the file vllm/model_executor/layers/utils.py of the component Penalty Handler. Performing a manipulation results in denial of service. Remote exploitation of the attack is possible. The exploit has been released to the public and may be used for attacks. The project was informed of the problem early through an issue report but has not responded yet.
CVE-2026-105775 is a medium severity vulnerability in vllm-project vLLM up to version 0.31.0. It involves an out-of-bounds read in the conv_ssm_forward function within the Completions Request Handler component. The vulnerability can be exploited remotely without user interaction or privileges. Public exploit disclosure exists, but no vendor response or patch is currently available.
vLLM is an inference and serving engine for large language models. Prior to 0.30.0, a caller can use the request-level media_io_kwargs field to select the GLMGA video backend and supply large values for the fps and max_frames options without a strict work ceiling. GLMGA constructs and deduplicates an attacker-sized pre-decode frame-index list, allowing a compact request and tiny valid video to consume disproportionate CPU time and memory in the shared media-loading executor. This issue is fixed in version 0.30.0.
CVE-2026-105758 is a resource allocation vulnerability in vllm versions 0.24.0 through 0.29.999 that allows unauthenticated attackers to submit excessive video frame and frame rate values to the /tokenize endpoint. This can cause disproportionate memory consumption and potentially terminate the API process. The issue is fixed in version 0.30.0.
vLLM is an inference and serving engine for large language models. Prior to 0.30.0, OpenAI-compatible request models accept a non-empty cache_salt value without enforcing the character and length restrictions required by the IPCCacheServerKey consumer in LMCache-MP. On deployments using the LMCache-MP connector, a salt that contains a forbidden character or exceeds the permitted length can raise an uncaught ValueError during scheduler cache lookup, causing EngineCore to terminate and denying service to all concurrent users. This issue is fixed in version 0.30.0.
vLLM versions prior to 0.30.0 contain an improper input validation vulnerability in the /inference/v1/generate endpoint. This flaw allows crafted inputs in several fields to cause termination of the shared EngineCore, poison or retrieve cross-request encoder-cache state, and alter replayed transport semantics. The issue is resolved in version 0.30.0.
vLLM is an inference and serving engine for large language models. In versions from 0.22.1 through 0.28.0, the operator-supplied model revision pin (--revision / --code-revision) is not propagated to several Hugging Face artifact loads for the FunAudioChat and Tarsier2 architectures: the WhisperFeatureExtractor and speech_tokenizer PreTrainedTokenizerFast loads in vllm/model_executor/models/funaudiochat.py and the Qwen2VLConfig.from_pretrained call used by Tarsier2ProcessingInfo in vllm/model_executor/models/qwen2_vl.py. As a result, deployments pinned to a reviewed revision still resolve these behavior-affecting processor, tokenizer, and config artifacts from the repository's default revision, so a later change to the upstream default branch can alter audio preprocessing, speech tokenizer behavior, or Tarsier2 configuration without any change to the operator's configured pin. This is a supply-chain integrity and reproducibility failure for pinned deployments; it is residual to the earlier fix tracked as GHSA-3ww4-5jv9-j5gm / CVE-2026-47155 and does not constitute remote code execution or a trust_remote_code=False bypass. The issue is fixed in version 0.28.0.
vLLM before 0.29.0 contains a resource-limit bypass vulnerability in PyNvVideoCodec decoder allocation where sampler subclass shadowing allows independent counter increments. Unauthenticated attackers can select different sampler subclasses in video requests to exceed configured decoder limits and exhaust unaccounted GPU memory.
vllm before 0.29.0 fails to enforce VLLM_MAX_AUDIO_CLIP_FILESIZE_MB limit in multimodal chat audio decoding, allowing unauthenticated clients to bypass file size restrictions. Attackers can submit oversized audio files through chat endpoints to consume excessive memory and CPU resources during decoding.
vLLM is an inference and serving engine for large language models. 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. An attacker able to submit video requests to a video-capable GPU deployment with PyNvVideoCodec installed can exhaust shared GPU memory, causing request failures, worker crashes, or denial of service. The first release containing the fix is version 0.28.0.
vLLM is an inference and serving engine for large language models. Prior to 0.24.0, the input_audio handling path for /v1/chat/completions calls AudioMediaIO.load_bytes or AudioMediaIO.load_file without passing VLLM_MAX_AUDIO_DECODE_DURATION_S to the shared audio decoder. An unauthenticated client can therefore submit a small compressed audio input that expands into a very large float32 PCM allocation, bypassing the duration guard already used by /v1/audio/transcriptions and causing an out-of-memory worker crash. Inline data URLs reach this path without being bounded by VLLM_AUDIO_FETCH_TIMEOUT. The issue affects deployments serving an audio-capable model, and authentication changes only the deployment-specific reachability. This issue is fixed in version 0.24.0.
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. It is possible to launch the attack remotely. The pull request to fix this issue awaits acceptance.
CVE-2026-92220 is a medium severity vulnerability in vllm-project vLLM versions 0.26.0 and 0.27.0. It affects the MoRIIO Acknowledgement Handler component, specifically functions handling request completion and release messages. An attacker can remotely manipulate certain arguments to cause resource consumption, potentially impacting system availability. No patch or vendor response has been reported yet.
CVE-2026-90878 is a resource consumption vulnerability in vllm-project vLLM versions 0.27.0 and 0.27.1. It affects the Jinja Template Rendering component in the /v1/chat/completions endpoint. The vulnerability is triggered by manipulation of the chat_template argument and can be exploited remotely without user interaction or privileges. A fix has been proposed but is not yet accepted. The vulnerability has a medium severity rating with a CVSS score of 5.3.
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.
CVE-2026-71486 is a medium severity vulnerability in vllm-project vllm versions prior to 0.26.0. It affects the /v1/completions/derender and /v1/chat/completions/derender API endpoints, which accept client-supplied generated output data without enforcing limits on token counts or response sizes. This allows an authenticated API client to cause uncontrolled CPU and memory consumption proportional to the size of the attacker-supplied token data, bypassing normal generation output bounds.