Inference infrastructure

A security flaw in vllm-project vLLM up to 0.31.0 affects the function get_token_bin_counts_and_mask in vllm/model_executor/layers/utils.py, part of the Penalty Handler component. Remote exploitation leads to denial of service, and a public exploit exists. The project was notified through an issue report but has not yet responded.

A security vulnerability in vllm-project vLLM up to 0.31.0 affects the function conv_ssm_forward in vllm/model_executor/layers/mamba/mamba_mixer2.py, within the Completions Request Handler component. Manipulation of this component leads to an out-of-bounds read, and the attack can be carried out remotely. The exploit has been publicly disclosed and may be used, and the project was informed through an issue report but has not yet responded.

An unauthenticated attacker can exhaust memory in the vLLM API-server process on Qwen2-VL and Qwen3-VL deployments by raising the request-level media_io_kwargs.video.max_frames and fps values. The Qwen video samplers never read num_frames, so the num_frames ceiling in PR #51969 does not stop this path, while the same knobs were already capped for GLMGAVideoBackend in commit 8b6de0eb9. In the reporter's test, 74 extra bytes of JSON sent over POST /tokenize raised peak RSS from 2 271 MiB to 13 629 MiB.

vLLM's OpenAI-compatible chat endpoint accepts request-level `media_io_kwargs`, so a caller can select the GLMGA video sampler and set large `fps` and `max_frames` values. GLMGA builds and deduplicates an attacker-sized index list before frame reads, so a tiny valid video with compact JSON options can consume disproportionate CPU and memory in the shared media-loading executor and delay unrelated media requests. The demonstrated impact is partial denial of service, with no memory corruption, data disclosure or code execution claimed.

vLLM versions up to and including 0.25.1 are affected through the disaggregated scale-out transport. The POST /inference/v1/generate route decodes a caller-supplied features object (kwargs_data, mm_hashes, mm_placeholders) and passes it to the engine as if it came from the trusted render step, without validating it against the active model's renderer output. Any authenticated caller can forge one field to crash the shared EngineCore process, poison or disclose cross-request encoder-cache state, or drop placeholder masks during replay.

vLLM versions up to and including 0.25.1 contain three structured-output request paths that raise an uncaught, engine-fatal exception instead of a per-request validation error. The exception escapes into EngineCore's busy loop and triggers a fatal _send_engine_dead(), so one malformed structured-output request denies service to all concurrent and subsequent users of that engine. Site 1 is a valid duplicate-root EBNF grammar that the latched xgrammar backend fails to compile, and the completion check catches only TimeoutError. The advisory states that these sites are distinct from the fixes in GHSA-6qc9-v4r8-22xg and GHSA-8wr5-jm2h-8r4f.

vLLM versions up to and including 0.25.1 cache late-interaction query embeddings on `/score` and `/rerank` under a key derived from the caller-supplied `X-Request-Id` header when flash late interaction is enabled, which is the default for supported models. A concurrent request reusing the victim's header value replaces the victim's cached query embedding, so the victim's documents are scored against the attacker's query, and one request can also force the other into a late-interaction cache-miss error. The source states the lower bound of affected versions is not confirmed and maintainers can confirm it.

vLLM's OpenAI-compatible request models (Completions, Chat Completions, Responses) accept a client-supplied `cache_salt` validated only as a non-empty string. With the built-in LMCache-MP KV connector enabled, the value reaches the scheduler's cache lookup unguarded, and the downstream LMCache `IPCCacheServerKey.__post_init__` raises an uncaught `ValueError` for `@`, `/`, `\`, NUL or lengths over 128 characters. Because the exception is never caught on the scheduling path, a single request such as `cache_salt="/"` kills EngineCore for all users.

vLLM, an inference and serving engine for large language models, is affected before version 0.30.0 by a flaw in the Rust frontend's track_http_metrics middleware. The middleware records the raw HTTP method token as a Prometheus label on requests reaching registered routes, so an unauthenticated attacker sending unique arbitrary method tokens to unguarded routes such as /tokenize can permanently create label sets. This increases process memory usage and enlarges the /metrics response until the service or monitoring path is exhausted.

CVE-2026-105753 affects vLLM, an inference and serving engine for large language models, prior to 0.28.0. The default mirrored multimodal LRU cache can record a media hash in the frontend sender cache before engine admission, while the engine receiver cache never gets the payload if the request is rejected. A later request reusing that media hash makes the receiver cache hit an assertion, causing an availability failure in the shared service.

A flaw in the Gemma4UnifiedParser component of vllm-project vLLM up to 0.26.0, located in rust/src/parser/src/unified/gemma4.rs, can be triggered remotely through a manipulated input to cause a denial of service. Public exploit code has been published, so the flaw can be used by attackers.

vLLM before 0.29.0 accepts user-controlled stop_token_ids on the OpenAI-compatible POST /v1/completions and POST /v1/chat/completions endpoints, validating only that the values are integers rather than that each id falls within the model vocabulary or logits range. When min_tokens is greater than 0, an out-of-range id reaches a CUDA index_put_ operation and triggers a device-side assertion. An authenticated API user can send one malformed request that returns 500 Internal Server Error and leaves EngineCore in a fatal state, so later requests fail until the service restarts (denial of service).

CVE-2026-100653 affects vLLM versions 0.22.1 through 0.28.0. The operator-supplied model revision pin (--revision / --code-revision) is not applied to several Hugging Face artifact loads for the FunAudioChat and Tarsier2 architectures, including the WhisperFeatureExtractor and speech_tokenizer loads in vllm/model_executor/models/funaudiochat.py and the Qwen2VLConfig.from_pretrained call in vllm/model_executor/models/qwen2_vl.py. Pinned deployments therefore resolve these artifacts from the repository's default revision, so upstream changes can alter audio preprocessing, speech tokenizer behavior, or Tarsier2 configuration without any change to the pin.

vLLM versions 0.22.0 through 0.23.0 do not validate stop_token_ids against vocabulary bounds in the Rust HTTP and gRPC frontends, so out-of-vocabulary token IDs reach MinTokensLogitsProcessor. An attacker can send requests with min_tokens greater than zero and out-of-vocabulary stop_token_ids to trigger CUDA tensor indexing failures, which leave EngineCore in a fatal state that requires a service restart.

vLLM versions before 0.29.0 do not enforce decoder prompt-length validation on the disaggregated serving endpoint /inference/v1/generate when a request includes a 'features' multimodal payload. The GenerateRequest.token_ids list is not checked against model_config.max_model_len, and processors reporting skip_prompt_length_check=True (such as Nemotron Parse, Whisper, and FireRedLID) bypass validation entirely. A client that can reach the endpoint on an affected configuration can submit an overlong token_ids list and crash the worker, causing denial of service.

vLLM through 0.29.0 fetches and fully reads remote or inline media before enforcing its documented media controls, the VLLM_MAX_AUDIO_CLIP_FILESIZE_MB audio size cap and the --limit-mm-per-prompt item limits. Across four ingress paths, including the chat completions audio_url and base64 path and the unauthenticated Rust frontend POST /tokenize route, a remote attacker can force memory and outbound bandwidth use proportional to an attacker-chosen body size or media item count before rejection. The result is pre-inference memory and bandwidth exhaustion, a denial of service. The source states no code execution or data disclosure impact.