vLLM from 0.7.3 before 0.31.0 contains an uncontrolled resource consumption vulnerability that allows remote clients to control multimodal processor parameters by supplying per-request mm_processor_kwargs. Attackers can set large image size, patch count, crop count, or frame count values in Isaac, InternVL, H2OVL, and other processors to exhaust memory and terminate the shared server.
vLLM versions before 0.31.0 have an improper access control vulnerability involving cache aliasing. Authenticated attackers can manipulate shared cache keys by supplying controlled values like EXIF ImageID or cache_salt. This allows attackers to access cached processed media from other requests or reuse key-value state, potentially leading to unauthorized data access.
vLLM versions from 0.7.3 up to but not including 0.31.0 contain a code injection vulnerability. This occurs because the software forwards user-supplied code revision parameters to Transformers AutoProcessor.from_pretrained when trust_remote_code is enabled, allowing an attacker to execute arbitrary Python code via the unauthenticated /tokenize endpoint.
vLLM after 0.24.0 and before 0.31.0 contains a memory exhaustion vulnerability in MOSS-Audio model serving that caches a processor for every distinct request-controlled mm_processor_kwargs value in an unbounded dictionary. Unauthenticated attackers can send distinct or oversized mel_config values to the /tokenize endpoint, which bypasses --api-key, to exhaust host memory and crash the API process.
vLLM versions before 0.31.0 have a vulnerability where the min_tokens <= max_tokens check is skipped if max_tokens is null in /inference/v1/generate requests. This causes an uncaught exception that hangs all subsequent generation requests until the service is manually restarted. The vulnerability can be triggered by unauthenticated remote attackers sending a single request with an oversized min_tokens value.
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 by leaving stale allowed_token_ids rows, which results in token allowlists from one request being applied to another. Attackers can exploit this by submitting concurrent constrained generate requests, including through unauthenticated /invocations endpoints.
vLLM versions before 0.29.0 improperly validate input by only checking file size when passing uploaded audio to the PyAV/FFmpeg av.open() fallback. This exposes a heap overflow vulnerability in FFmpeg's IAMF parser. Authenticated remote attackers can exploit this by uploading malformed IAMF containers to the /v1/audio/transcriptions endpoint, causing heap corruption and crashing the API process.
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.
vLLM is an inference and serving engine for large language models. Prior to 0.30.0, the Rust frontend's track_http_metrics middleware records the raw HTTP method token as a Prometheus label for requests reaching registered routes. An unauthenticated attacker can send unique arbitrary method tokens to unguarded routes such as /tokenize, causing Prometheus's Family::get_or_create function to permanently create counter and histogram label sets. Those label sets increase process memory usage and enlarge the /metrics response until the service or monitoring path is exhausted. 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, structured-output request failures can escape request-scoped validation and reach the EngineCore fatal-error path. A per-request backend mismatch can re-raise a grammar compilation exception, padding produced by the ngram_gpu speculative-decoding mode can pass a negative token to guidance validation, and the Rust frontend can admit empty structured-output values that the Python frontend rejects, allowing ordinary constrained-generation requests to terminate the shared engine. This 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 is an inference and serving engine for large language models. Prior to 0.30.0, flash late-interaction scoring at the /score and /rerank endpoints derives each worker's query_key value from the caller-controlled X-Request-Id header. A concurrent request that reuses a victim's identifier can overwrite the cached query embedding so the victim's documents are scored against the attacker's query, and shared use counters can also cause a late-interaction cache-miss error. 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. Prior to 0.28.0, the default mirrored multimodal LRU cache can commit a media hash in the frontend sender cache during multimodal rendering and before engine admission, while the engine receiver cache never receives the payload if that request is rejected. A later request reusing the same media hash causes MultiModalProcessorSenderCache to send no payload and MultiModalReceiverCache to reach an assertion with the message "Expected a cached item," producing a shared-service availability failure. This issue is fixed in version 0.28.0.
vLLM is an inference and serving engine for large language models. Prior to 0.30.0, Harmony tool continuations submitted through "POST /v1/responses" requests rebuild the next-turn engine input without preserving the cache_salt value, placing the continuation prefix in the global unsalted cache namespace even when the caller enabled salting. On deployments with prefix caching enabled, which is the default, an authenticated tenant who can reconstruct a victim's low-entropy post-tool history can submit the same continuation and use the cached_tokens_per_turn count to determine whether the prefix was previously processed, defeating the intended tenant isolation of salted prefix caching. This issue is fixed in version 0.30.0.
CVE-2026-103241 is a denial of service vulnerability in the vllm-project vLLM software affecting versions 0.1 through 0.26.0. The flaw exists in the Gemma4UnifiedParser component within the rust/src/parser/src/unified/gemma4.rs file. An attacker can remotely trigger this vulnerability to cause a denial of service. A patch is available in version 0.29.1rc0, which addresses this issue.