Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
89 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The OpenAI-compatible server registers Starlette `CORSMiddleware` with `allowed_origins` defaulting to `["*"]`, and performs no authentication unless `--api-key` (or `VLLM_API_KEY`) is configured. A web page on any origin can send requests to a vLLM server that the victim's browser can reach (for example `localhost` or an internal/VPN address) and read the responses. The default `allow_credentials=False` blocks cookie-bearing cross-origin requests; because vLLM authenticates with a bearer header rather than cookies, the wildcard still permits untokenized access to an unauthenticated server and read access when the caller already holds a token. Details Affected components - `vllm/entrypoints/launchers/cli_args.py` - `allowed_origins` default value. - `vllm/entrypoints/serve/middleware/register.py` - `CORSMiddleware` registration. - `vllm/entrypoints/serve/middleware/authenticate.py` - auth middleware and its guarded path prefixes. Root cause…
Recommended action: Upgrade to 0.32.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Phi-4 multimodal audio encoder (`phi4mm_audio.py` / `phi4mm_utils.py`) runs its conformer attention in eager mode by default: the official HF config of `microsoft/Phi-4-multimodal-instruct` does not set `use_pt_scaled_dot_product_attention`, so the default `False` applies (`phi4mm_audio.py:166`, `:876`; `phi4mm_utils.py:1669`). The eager path fully materializes the attention probability matrix of shape `[n_chunks, 16, 500, 500]` per layer — and then stores it on the module: `self.attn = attn` (`phi4mm_utils.py:1802`, a `torch.jit.Attribute` declared at `:1693`), keeping a live reference for every one of the 24 encoder layers. The only gates on audio length are the server-side limits `VLLM_MAX_AUDIO_CLIP_FILESIZE_MB=25` and `VLLM_MAX_AUDIO_DECODE_DURATION_S=600` (`envs.py:83-84`) — i.e. a 10-minute clip is a legal input by default. A 600 s clip becomes ~60,000 mel frames, which the encoder unfolds into 500-frame chunks (`phi4mm_audio.py:996`, `max_seq_len =…
Recommended action: Upgrade to 0.32.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Any vLLM deployment serving a model of the DeepSeek-OCR family — `deepseek-ai/DeepSeek-OCR`, `deepseek-ai/DeepSeek-OCR-2`, or `baidu/Unlimited-OCR` (whose `UnlimitedOCRForCausalLM` subclasses `DeepseekOCRForCausalLM`) — can be killed by a single unauthenticated chat request carrying an ordinary, schema-valid PNG image, under completely default server configuration. The image model's input validation contains a guard inherited from the upstream DeepSeek-OCR reference implementation: ```python vllm/model_executor/models/deepseek_ocr.py:478-479 (_parse_and_validate_image_input) if torch.sum(pixel_values).item() == 0: return None ``` In the original research code this was an empty-batch shortcut; in vLLM's serving architecture `pixel_values` is the actual client image tensor, and the condition is exactly satisfiable by a legitimate image: the in-tree `DeepseekOCRProcessor` normalizes pixels with `ToTensor + Normalize(0.5, 0.5)`…
Recommended action: Upgrade to 0.32.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In vLLM 0.30.0, `ImageMediaIO` passes attacker-controlled image bytes to Pillow's format autodetection without restricting the accepted formats; the request's MIME label does not constrain decoder selection. An EPS payload labeled `image/png` reached the host's Ghostscript executable. On a host with Ghostscript affected by CVE-2024-29510, this exposes the known Ghostscript sandbox escape through vLLM's image-loading path and can execute commands with the vLLM process's privileges. A bounded marker-command payload executed through the PyPI wheel's actual `ImageMediaIO.load_base64()` implementation using Debian Ghostscript 10.03.0. The loader-level execution is reproduced; the HTTP request path is source-traced but was not exercised end to end. This report concerns vLLM's untrusted-format dispatch and does not claim a new Ghostscript vulnerability. Exploitation requires an image-capable request path, a caller able to reach it under the deployment's authentication policy,…
Recommended action: Upgrade to 0.32.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Affected - Ecosystem / package: pip / `vllm` - Affected versions: vLLM MultiModalKwargsItem: assert mm_item is not None, f"Expected an address item for {mm_hash=}" if "address" in mm_item: address = cast(int, mm_item["address"].data) monotonic_id = cast(int, mm_item["monotonic_id"].data) return self._shm_cache.get(address, monotonic_id) return mm_item ``` The dereference lands in the SHM deserializer, which `pickle.loads()` any chunk tagged as `bytes` — so attacker bytes staged in the ring buffer are unpickled in the worker process: ```python vllm/distributed/device_communicators/shm_object_storage.py Lines 375-400 def deserialize(self, data_view: memoryview) -> Any: pickle.loads do not read past the end of a pickled object within a large buffer, so we can skip storing the metadata size type_name, nbytes, len_arr = pickle.loads(data_view) serialized_data = data_view[-nbytes:] if type_name == torch.Tensor.name: obj = [] start_idx = 0 for length in len_arr:…
Recommended action: Upgrade to 0.32.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
For a model whose vocabulary size is an exact multiple of the embedding padding size (64) — e.g. any Llama-2-family model, vocab 32000 — a single request carrying a pre-tokenized prompt with token id equal to the vocab size (32000) passes vLLM's input-id validation but is one past the last embedding row. At tensor-parallel size 1 the embedding lookup does not mask indices, so the id reaches `F.embedding` out of range and raises a CUDA device-side assert, which poisons the engine's CUDA context and takes the engine down. Any client that can send pre-tokenized input (`/v1/completions` with `prompt` as token ids, `/tokenize`-fed flows, or the `kv_transfer_params["prompt_token_ids"]` reuse path) can trigger it. Root cause `vllm/v1/engine/input_processor.py` accepts a token id when `id 1 masks via `get_masked_input_and_mask`, so the id is clamped, not an OOB — likely wrong output rather than a crash. - Models whose vocab is a multiple of 64 with `tokenizer.vocab_size` one past the max…
Recommended action: Upgrade to 0.32.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
vLLM's `/v1/responses` endpoint accepts request-level `chat_template_kwargs`, but does not apply the `--trust-request-chat-template` gate that protects Chat Completions, render, tokenize, and pooling paths. When the server is run with the documented default `trust_request_chat_template=False` and no explicit `--chat-template`, a Responses request can pass: ```json {"chat_template_kwargs": {"chat_template": " "}} ``` That key is preserved by `ChatParams.get_apply_chat_template_kwargs()` and then bound as the `chat_template` parameter to the shared HF renderer. Prior vLLM advisories establish that request-controlled Jinja chat templates can cause CPU/memory exhaustion. This report covers the current-head Responses sibling path missed by the earlier fixes. Technical Details The shared OpenAI frontend has a validation helper that rejects request-supplied chat templates unless the trust flag is enabled. It explicitly checks both top-level `chat_template` and…
Recommended action: Upgrade to 0.32.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
vLLM renders chat templates by passing the resolved Jinja2 source to `tokenizer.apply_chat_template()`, which compiles and `.render()`s it in an `ImmutableSandboxedEnvironment`. The sandbox prevents code-execution escapes but imposes no wall-clock timeout, no output-size cap, and no nested-loop or binop limit. The render runs in a `ThreadPoolExecutor` whose `max_workers` defaults to 1, and CPython worker threads cannot be interrupted. An authenticated API client (or a malicious model repo loaded with `trust_remote_code=False`) can therefore submit a single short template and permanently wedge all chat-style endpoints (`/v1/chat/completions`, `/v1/responses`, `/tokenize`, `/pooling`-chat, `/invocations`-chat) for every tenant until the process is restarted. A string-multiplication variant instead OOM-kills the API-server process. Because of a separately-reported (GHSA-jmjw-q4x3-hmc2) gate omission on `/v1/responses`, the remote authenticated attacker vector…
Recommended action: Upgrade to 0.32.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An untrusted multimodal request can set `mm_processor_kwargs.code_revision`. When vLLM serves a model whose Hugging Face processor uses dynamic `auto_map` code and the operator enabled `--trust-remote-code`, this request value reaches `AutoProcessor.from_pretrained` and selects the Python revision imported by Transformers. This lets a client replace the operator-reviewed processor module with code from another revision of the same model repository. The operator-selected model/data `revision` remains pinned; only the executed processor code changes. Importing a Python module is arbitrary code execution in the vLLM API/renderer process. The PoC below demonstrates this with an import-time filesystem write. It is fully offline and does not require a GPU, model weights, or changes to a real Hub repository. Affected snapshot - Repository: `vllm-project/vllm` - Verified commit:…
Recommended action: Upgrade to 0.31.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When the `OffloadingConnector` uses `TieringOffloadingSpec` with a P2P secondary tier, an API client can submit many unique non-listening peer addresses through `kv_transfer_params.prefill`. vLLM keeps every never-established P2P session and its ZeroMQ sockets after the request finishes. On vLLM 0.26.0, 340 such peers filled the default ZeroMQ context socket quota; creating the next peer raised an uncaught `ZMQError`, terminated `EngineCore`, and shut down the API server. The path was reproduced with a normal API key and no access to the internal P2P listener. Details Root cause In vLLM 0.26.0, `P2PSecondaryTierManager.on_new_request()` reads the following request-controlled fields: ```json { "kv_transfer_params": { "prefill": { "kv_request_id": "id", "remote_host": "127.0.0.1", "remote_port": 49101 } } } ``` `on_new_request()` calls `_get_or_create_session(peer_id)`. This calls `ZmqTransport.connect()`, creates a `P2PSession`, and stores it in `_sessions` before…
Recommended action: Upgrade to 0.32.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
vLLM from 0.20.0 before 0.30.0 contains a denial of service vulnerability that allows remote attackers to crash the engine by sending inconsistent multimodal metadata to the disaggregated /inference/v1/generate endpoint. Attackers can replay a valid multimodal item with repeated or overlapping mm_placeholders ranges or mismatched kwargs_data and mm_hashes lists, producing a negative text span in Qwen2.5-VL position construction that terminates the engine.
Recommended action: Upgrade to 0.30.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
vLLM from 0.10.2 before 0.25.0 contains an uncontrolled resource consumption vulnerability that allows unauthenticated attackers to exhaust memory because the Nemotron-VL processors globally set Image.MAX_IMAGE_PIXELS to None. Attackers can submit a pathological decompression-bomb image to /v1/chat/completions to OOM-kill the worker and deny service to co-tenants.
Recommended action: Upgrade to 0.25.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
vLLM from 0.9.2 before 0.24.0 contains a server-side request forgery vulnerability that allows API callers to force outbound connections by embedding a decode address in the X-Request-Id header. Attackers can make a P2pNcclConnector prefill worker ZMQ-connect to an attacker host, leaking the NCCL unique_id and KV-cache tensors or blocking the worker.
Recommended action: Upgrade to 0.24.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
vLLM from 0.22.0 before 0.24.0 contains a denial of service vulnerability that allows remote attackers to terminate EngineCore by bypassing logprob_token_ids limits in the Rust gRPC frontend. Attackers can send Generate or GenerateStream requests with output_logprobs enabled and more than 128 output_candidates.token_ids, triggering a fatal sampler exception that crashes the engine.
Recommended action: Upgrade to 0.24.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
API clients can supply arbitrary mmprocessorkwargs per request. vLLM forwards these values through the multimodal rendering and processing pipeline to Hugging Face and custom image/video processor constructors and calls. Resource-sensitive values such as image size, patch size, patch count, crop count, or frame count can therefore be controlled by a remote client. For processors that upscale inputs, a single request can force an allocation large enough to terminate the API server or worker with an out-of-memory condition. Affected Components The per-request field was introduced in commit 041e29471671a3d43afedb6a749421d56ef4d3e7 and first shipped in v0.7.3. The generic forwarding path remains present in current main. The Isaac path is a concrete high-amplification example: - ChatCompletionRequest.mmprocessorkwargs - OnlineRenderer request extras - MMProcessorInputs.hfprocessormmkwargs - BaseMultiModalProcessor.info.gethfprocessor(hfprocessormmkwargs) -…
Recommended action: Upgrade to 0.31.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Multimodal content parts (imageurl, videourl, inputaudio, ...) accept a user-supplied uuid field that vLLM uses verbatim as the item's cache identity (mmhash). The two frontend/engine processor caches (P0 "sender" cache in the API process, P1 "receiver" cache in the EngineCore process) are independent LRU caches whose evictions are not synchronized, and the P1 hit path performs zero consistency validation — it silently substitutes the cached item's tensor data for whatever the current request actually contains. A single unauthenticated client can exploit this to kill the entire engine, deterministically, with default server flags: 1. Seed: send a small image with uuid="U". Both caches now map U to an item with NA visual tokens (e.g. 4). 2. Drift: send ~70 requests, each carrying a unique uuid, a max-size image, and an over-long text prompt. Each request is rejected with 400 — but after its image has been inserted into the P0 cache (insertion happens during chat rendering,…
Recommended action: Upgrade to 0.31.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Affected - Ecosystem / package: pip / vllm - Affected versions: vLLM ≤ 0.25.1 (confirmed on 0.25.1, commit 752a3a504485). The lower bound predates 0.25.1; maintainers can confirm how far back the mirrored sender/receiver cache protocol reaches. Summary vLLM's default multimodal cache (mmprocessorcachetype="lru") mirrors state across two processes: the frontend (P0) holds only metadata (MultiModalProcessorSenderCache) while the engine core (P1) holds the real payload (MultiModalReceiverCache). The design invariant is that getandupdate() runs on P0 and P1 in lockstep for every request, so eviction order stays mirrored and P0 can answer "is this cached in P1?" without talking to P1. That invariant breaks when a request is rejected after P0 has rendered and hashed the multimodal input (populating the P0 cache) but before P1 receives the item — for example, an oversized chat prompt rejected on maxmodellen after rendering. P0 now believes the media is cached while P1 never got it. A later…
Recommended action: Upgrade to 0.28.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Affected - Ecosystem / package: pip / vllm - Affected versions: vLLM ≤ 0.25.1 (confirmed on 0.25.1, commit 752a3a504485). The lower bound predates 0.25.1; maintainers can confirm how far back the tool-continuation re-submission has omitted the salt. Summary On the GPT-OSS "Harmony" path (POST /v1/responses), a request that uses a built-in or MCP tool runs as a multi-turn loop: after each tool call vLLM re-renders the full next-turn Harmony prompt and re-submits it to the engine. Turn 1 correctly carries request.cachesalt, but the tool-continuation re-submission rebuilds the engine input via tokensinput(tokenids) with no cachesalt. The continuation prefix is therefore cached in the global unsalted namespace even though the caller opted into salting. A second tenant who can guess the low-entropy post-tool history submits the reconstructed continuation (unsalted) and reads exact per-turn cached-token counts from the Responses usage — restoring the prompt-membership oracle that cachesalt…
Recommended action: Upgrade to 0.30.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An unauthenticated remote attacker can exhaust the memory of the vLLM API-server process by raising the request-level mediaiokwargs.video.maxframes and fps knobs on any deployment serving a Qwen2-VL or Qwen3-VL model. 74 extra bytes of JSON took the server's peak RSS from 2 271 MiB to 13 629 MiB over unauthenticated POST /tokenize. The numframes ceiling reported in GHSA-vxqj-p4gw-9h4c and fixed by open PR #51969 does not reach this path: the Qwen samplers do not read numframes at all. The same knobs were already capped upstream for GLMGAVideoBackend as an accepted security fix in 8b6de0eb9 (PR #54935, merged 2026-09-04); that cap never reached Qwen. Details Relationship to GHSA-vxqj-p4gw-9h4c and PR #51969 (read this first) GHSA-vxqj-p4gw-9h4c reported that request-level mediaiokwargs.video.numframes overrides the engine frame-count ceiling, and open PR #51969 fixes it by clamping numframes inside VideoMediaIO.mergekwargs. That clamp does not reach the Qwen samplers.…
Recommended action: Upgrade to 0.30.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The OpenAI-compatible chat endpoint accepts request-level video loader options through mediaiokwargs. A caller can select the GLMGA sampler and provide large fps and maxframes values. GLMGA first constructs an attacker-sized Python index list and then deduplicates it, even when the supplied video contains only a few frames. This work occurs in the shared media-loading executor before frame reads, allowing a tiny valid video and compact JSON options to consume disproportionate CPU time and memory and delay unrelated media requests. The demonstrated impact is partial denial of service. No memory corruption, data disclosure, or code execution is claimed. Affected configuration The server must expose chat completions for a video-capable model and accept request-level mediaiokwargs. The model does not need to use GLMGA by default because the request value overrides the model's loader mapping. The proof of concept uses an inline two-frame video and explicitly selects the OpenCV…
Recommended action: Upgrade to 0.30.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Affected - Ecosystem / package: pip / vllm - Affected versions: vLLM ≤ 0.25.1 (confirmed on 0.25.1, commit 752a3a504485). The lower bound predates 0.25.1; maintainers can confirm how far back the scale-out transport path reaches. Summary vLLM's disaggregated scale-out transport splits a multimodal request into a trusted render step (POST /v1/chat/completions/render) and a separate generate step (POST /inference/v1/generate). The generate route decodes a caller-supplied features object — serialized encoder tensors (kwargsdata), multimodal hashes (mmhashes), placeholder ranges (mmplaceholders), and the internal field-processor selection — and forwards it into the engine as if it had come from the trusted renderer, with no rebinding to (or validation against) the active model's renderer contract. Because the two routes are ordinary auth-guarded HTTP endpoints (the /inference prefix is registered by default on generate-capable servers), any authenticated caller can submit an…
Recommended action: Upgrade to 0.30.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Affected - Ecosystem / package: pip / vllm - Affected versions: vLLM ≤ 0.25.1 (confirmed on 0.25.1, commit 752a3a504485). The lower bound predates 0.25.1; maintainers can confirm how far back each path reaches. Summary Three structured-output request paths let an ordinary request reach a condition that raises an uncaught, engine-fatal exception instead of a per-request validation error. The failure is not confined to the request that caused it: it escapes into EngineCore's busy loop and triggers a fatal sendenginedead(), so one malformed structured-output request denies service to all concurrent and subsequent tenants of that engine. The requests are ordinary API calls; the client does not need any privileged configuration beyond the (often default) structured-output feature. The shared root cause is the absence of a per-request exception boundary around structured-output grammar/token handling: a value that should fail as a request-scoped validation error instead propagates as an…
Recommended action: Upgrade to 0.30.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Affected - Ecosystem / package: pip / vllm - Affected versions: vLLM ≤ 0.25.1 (confirmed on 0.25.1, commit 752a3a504485). The lower bound predates 0.25.1; maintainers can confirm how far back the flash late-interaction query cache reaches. Summary On late-interaction /score and /rerank deployments with flash late interaction enabled (the default for supported models), the worker caches per-request query embeddings under a key derived from the caller-controlled X-Request-Id header. A second concurrent request that reuses the victim's header value replaces the victim's cached query embedding before document scoring — so the victim's documents are scored against the attacker's query. Because the data-parallel router pins all requests sharing a cache key to the same engine, the collision is deterministic for an attacker who reuses the victim's X-Request-Id. Depending on timing, one request can also consume the shared use counter and force the other request into a late-interaction…
Recommended action: Upgrade to 0.30.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Affected - Ecosystem / package: pip / vllm - Affected versions: vLLM ≤ 0.25.1 (confirmed on 0.25.1, commit 752a3a504485). The lower bound predates 0.25.1; maintainers can confirm how far back the loose cachesalt validator and unguarded scheduling-path lookup reach. Summary vLLM's OpenAI-compatible request models (Completions, Chat Completions, Responses) accept a client-supplied cachesalt field and validate it only as "must be a non-empty string" — no character or length restrictions. On a deployment with the built-in LMCache-MP KV connector enabled, that value is stored verbatim on the request tracker and forwarded unguarded as a keyword argument into the scheduler's per-step cache lookup. The downstream LMCache library applies a stricter check in IPCCacheServerKey.postinit, which raises ValueError for any cachesalt containing @, /, \, or NUL (or longer than 128 characters). Neither the LMCache-MP connector lookup call site nor Scheduler.schedule() wraps that call in a…
Recommended action: Upgrade to 0.30.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Current vLLM main lets an inference request choose the PyNvVideoCodec GPU video decoder through mediaiokwargs.video.videobackend, but engine GPU memory reservation is computed only from static startup configuration and VLLMVIDEOLOADERBACKEND. If the server starts with the default OpenCV/software backend and no --mm-ipc-gpu-memory-gb budget, a client can still route a video request into the PyNvVideoCodec path after startup, causing frontend CUDA-context, decoder-surface, and decoded-frame GPU allocations that were not carved out of the engine KV-cache budget. Technical Details The vulnerable boundary is the split between request-time media decoding choices in the API server and startup-time memory budgeting in the engine worker. Request bodies for Chat Completions and Responses expose mediaiokwargs, and those values are forwarded to the shared media connector. For video inputs, MediaConnector.fetchvideo() copies self.mediaiokwargs["video"] into videoiokwargs, only setting a…
Recommended action: Upgrade to 0.28.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.