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.
A security flaw has been discovered in vllm-project vLLM up to 0.29.0. The affected element is the function TiktokenTokenizer::new of the file rust/src/text/src/backend/hf/mod.rs of the component tiktoken vocab File Handler. The manipulation results in denial of service. The attack is only possible with local access. The exploit has been released to the public and may be used for attacks. The pull request to fix this issue awaits acceptance.
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 versions before 0.27.0 have a vulnerability where DeepStream is not properly classified as a GPU backend, leading to omission of pixel-limit enforcement in the decode path. This allows unauthenticated attackers to activate DeepStream at request time, initializing the GPU decode pool and submitting video that bypasses resource controls, causing partial denial of service for concurrent requests.
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.
A Server-Side Request Forgery (SSRF) vulnerability exists in vllm-project's vllm prior to version 0.26.0. The MiMoV2OmniMultiModalProcessor improperly handles attacker-controlled image and audio inputs by bypassing domain and local path restrictions, allowing unauthorized server-side requests and file reads accessible to the vLLM process. This vulnerability is fixed in version 0.26.0.
CVE-2026-73557 is a race condition vulnerability in the vllm-project's vllm software affecting versions from 0.20.2rc0 up to but not including 0.26.0. It arises from improper synchronization of a process-global sparse tensor invariant guard in PyTorch 2.11.0 during concurrent prompt-embedding reconstruction within a single chat completion request. This can lead to invalid sparse tensor deserialization and subsequent unsafe dense tensor conversion. The vulnerability requires the --enable-prompt-embeds feature (default off) but does not require multiple workers or multimodal embeddings. The flaw allows a malicious payload to bypass the follow-up guard, potentially causing memory corruption or denial of service as documented in the related CVE-2025-62164. The CVSS 4.0 base score is 6.3 (medium severity).
CVE-2026-73556 is a denial-of-service vulnerability in the vllm project's lm-format-enforcer backend. The backend compiles attacker-supplied regular expressions without a timeout or buildability check, allowing a crafted regex to stall the engine worker by consuming excessive CPU. This issue affects versions of vllm prior to 0.26.0 when the lm-format-enforcer backend is explicitly enabled. The default backend is not affected. The vulnerability results in unauthenticated denial of service by hanging the structured-output compile step and blocking concurrent requests.
vLLM versions prior to 0.26.0 have a vulnerability where malformed API requests cause error messages to leak sensitive internal information such as file paths, line numbers, OS username, home directory, Python version, and internal package structure. This occurs because the error handler converts validation exceptions to strings that include traceback details, which are insufficiently sanitized before being returned in HTTP responses. This information disclosure can aid attackers in fingerprinting the environment and crafting targeted exploits. The issue affects all POST endpoints accepting JSON bodies. A fix is available in vLLM 0.26.0 that changes the error handling to avoid leaking such details.
CVE-2026-73559 is a medium severity vulnerability in vllm, an inference and serving engine for large language models. Versions from 0.19.0 up to but not including 0.26.0 allow an authenticated API client to send a CompletionRequest with an unbounded list of prompts. This leads to uncontrolled resource consumption, exhausting CPU, memory, async scheduling capacity, engine request slots, and response buffering. The issue is fixed in version 0.26.0.
vLLM is an inference and serving engine for large language models. 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.
vLLM is a library for LLM inference and serving. From 0.12.0 to before 0.24.0, sending a pure prompt embeds payload in a /v1/completions request with a model using M-RoPE causes EngineCore to fail an assertion and fatally crash, shutting down the entire server application. Any remote user who is authorized to make a /v1/completions request can make such a request and induce a crash. This issue is fixed in version 0.24.0.
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Prior to 0.24.0, the structured_outputs.regex API parameter passes a user-supplied regular expression string directly to the grammar compiler backends with no compilation timeout; in the xgrammar backend the string reaches the regex compiler with no guard, and in the outlines backend the validation step blocks structural issues such as lookarounds and backreferences but performs no complexity analysis, so a pattern with nested quantifiers passes all checks and causes exponential state-space expansion, allowing a single request containing an adversarial regex to hang an inference worker indefinitely and deny service. This issue is fixed in version 0.24.0.
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Prior to 0.24.0, a frontend-legal multi-request speculative decoding workload can cause the rejection sampler to produce a recovered token equal to the model vocabulary size boundary value, which is then converted to negative one when the engine selects the next live token for a request and is written back into the drafter's input ids; that out-of-vocabulary value is later consumed by the model's embedding and attention path and crashes the engine worker with a GPU device-side assertion. The same triggering request sequence is reachable through the public gRPC Generate and Abort endpoints, so a remote client that can send generation requests can crash the shared engine worker, aborting concurrent requests and causing a service-wide denial of service for other clients of the deployment until the worker is restarted. This issue is fixed in version 0.24.0.
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.