Vllm Project
Monthly
vLLM before 0.32.0 lets untrusted image bytes pick their own Pillow decoder: ImageMediaIO calls Image.open(BytesIO(data)) without an allowlist and the declared MIME label does not constrain format selection, so an EPS payload submitted as image/png is dispatched to the host's Ghostscript. On hosts whose Ghostscript is affected by CVE-2024-29510 this chains to command execution with the vLLM process's privileges, and on environments running Pillow 12.0.0 through 12.2.0 the same boundary reaches CVE-2026-59203, where a malformed EPS parks media-loading workers until the pool is exhausted. The CVSS 3.1 vector is AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H (8.1 High), reflecting that reachability still depends on an image-capable endpoint, the deployment's API-key and network policy, and a vulnerable host dependency; the reported reproduction covered the loader-level command execution, while the HTTP request path was only source-traced. No public exploit code was identified at time of analysis, and CISA KEV does not list this CVE.
Authenticated inference callers on vLLM scale-out deployments that explicitly enable the shared-memory multimodal processor cache (--mm-processor-cache-type shm) can plant forged address and monotonic_id values inside the public features.kwargs_data envelope, causing a worker to dereference attacker-chosen ring-buffer memory and pass those bytes to pickle.loads(), which yields arbitrary Python execution in the worker process. The chain runs over ordinary public HTTP routes (/v1/chat/completions/render, /v1/chat/completions, /inference/v1/generate) and succeeds even with VLLM_ALLOW_INSECURE_SERIALIZATION=0 because it abuses the built-in SHM object deserializer rather than the optional insecure-serialization flag. Exposure is limited to deployments combining a scale-out topology with the non-default SHM cache mode; the flaw is fixed in vLLM 0.32.0, CISA KEV does not list it, and a proof-of-concept chain is described in the upstream advisory but no public working exploit code was confirmed at time of analysis.
Out-of-vocabulary stop_token_ids in vLLM 0.20.1 through 0.28.x allow a client able to submit generation requests to terminate the inference engine, causing denial of service for every other user sharing that server; on the V2 runner the same unchecked index can instead write outside the logits buffer and corrupt adjacent logits or other GPU state. The flaw is an input-validation gap: SamplingParams accepted any integer for stop_token_ids and those values became column indices into the model's logits tensor, so the OpenAI chat and completion paths, the legacy generate endpoint, and batch inputs are all affected. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VA:H) puts this at 7.1 with availability-only impact, and the PR:L metric is the main limiting factor, meaning the attacker needs the privileged capability to submit requests rather than being fully anonymous; no public exploit code or active exploitation has been identified at time of analysis, and priority is this-week remediation rather than emergency response.
Cross-tenant denial of service in vLLM 0.8.5 through 0.31.0 lets one API client crash the shared EngineCore process and drop every co-tenant request on that engine. The crash occurs when a request carrying prompt_logprobs (or echo with logprobs) is issued against a prefix that a KV connector reports as already computed, leaving positions in an uninitialized int32 tensor that the tokenizer then fails to decode, raising OverflowError. Reachability is conditional: the engine must be running the V1 engine with an active KVConnectorBase_V1 subclass returning num_new > 0 (LMCacheConnectorV1, NixlConnector, SharedStorageConnector, P2pNcclConnector, OffloadingConnector, MultiConnector), so plain vLLM without a KV transfer config is not exposed; no public exploit code or CISA KEV entry was identified at time of analysis, and the vendor advisory provides a patch.
Memory exhaustion in vLLM 0.18.0 through 0.30.x lets a client crash or OOM-kill the serving frontend by setting media_io_kwargs.video.num_frames to -1 (or an arbitrarily large positive value) alongside a large inline video/jpeg payload, so the API decodes and stacks every frame. Only deployments serving a video-capable multimodal model and honoring per-request media_io_kwargs are exposed; text-only instances are not affected, and versions before 0.18.0 lack runtime media_io_kwargs support. The CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N/VA:H) rates this a high-availability-impact, confidentiality- and integrity-neutral flaw, and no public exploit code has been identified at time of analysis, though the trigger is a simple documented parameter override.
Unauthenticated remote attackers can crash vLLM 0.20.0 through 0.29.x by submitting inconsistent multimodal metadata to the disaggregated /inference/v1/generate endpoint, which yields a negative text span in Qwen2.5-VL position construction and terminates the engine, denying service to subsequent requests. Exploitation is availability-only and rated high complexity: the attacker must first obtain and replay a valid multimodal item, then tamper with the serialized mm_placeholders, kwargs_data or mm_hashes fields, and the target must expose the scale-out multimodal generate endpoint. No public exploit code was identified at time of analysis; the validation fix ships in vLLM 0.30.0.
Memory exhaustion in vLLM's Nemotron-VL processor path allows unauthenticated remote callers to OOM-kill the inference worker and deny service to co-tenants. The Nemotron-VL processor modules set Pillow's Image.MAX_IMAGE_PIXELS to None at import time, permanently disabling the process-global decompression-bomb guard for every image decode in that process, so a pathological image submitted to /v1/chat/completions expands into unbounded memory. Exposure is limited to deployments that serve a Nemotron-VL model or otherwise import the affected processor modules, and the vendor fix ships in vLLM 0.25.0 via PR #47010; no public exploit code has been identified at time of analysis, and scoring is availability-only (CVSS 4.0 base 8.7, PR:N/UI:N).
Server-side request forgery in vLLM 0.9.2 through 0.23.x lets an API caller force a P2pNcclConnector prefill worker to open an outbound ZMQ connection to an attacker-chosen host by embedding a `___decode_addr_<host>:<port>` token in the `X-Request-Id` header, exposing the NCCL communicator unique_id and the KV-cache tensors of the targeted request and potentially stalling the worker on a blocking `ncclCommInitRank`. The flaw is conditional: it only applies to disaggregated-serving deployments started with `--kv-transfer-config` selecting the V1 `P2pNcclConnector` in the `kv_producer` role, and default vLLM installations are unaffected. The CVSS:4.0 vector indicates no privileges required (PR:N), with the caveat that a valid API key is needed when `--api-key` is configured. No public exploit was identified at time of analysis, and the vendor closed the issue in 0.24.0 by removing the affected connector.
Memory exhaustion in vLLM's multimodal chat audio path lets an authenticated API user submit a small compressed audio payload to /v1/chat/completions that decodes into very large PCM data, driving up server memory and degrading or halting availability. Deployments in the >= 0.19.0, < 0.24.0 range that accept audio content parts are affected; the fix in 0.24.0 extends the existing decoded-duration guard to AudioMediaIO, which currently calls load_audio(..., sr=None) with no max_duration_s bound. Exploitation requires a valid API key by default (PR:L) and an audio-capable deployment; no public exploit code was identified at time of analysis, and the issue is a sibling of the already-published speech-to-text decompression-bomb advisory.
A single crafted request to the Rust gRPC Generate or GenerateStream service in vLLM 0.22.0 through 0.23.x can abort EngineCore and leave the inference server unhealthy, producing a remote denial of service against availability only. Because the gRPC handlers forward attacker-supplied pre-tokenized prompt IDs to the engine without checking them against tokenizer or model vocabulary bounds, an out-of-vocabulary value such as 9000000 reaches the embedding lookup and terminates the process; no confidentiality or integrity impact is assessed. The vendor shipped a fix in 0.24.0, and no public exploit code has been identified at time of analysis - the main gating factor is whether the gRPC endpoint is network-reachable, since the advisory notes that deployments restricting it to already-authorized clients require that access and would score lower (PR:L, 6.5).
Remote denial of service in vLLM 0.22.0 up to but not including 0.24.0 allows remote attackers (CVSS PR:N) to crash EngineCore by sending a single Generate or GenerateStream request to the Rust gRPC frontend with output_logprobs enabled and more than 128 output_candidates.token_ids. The Rust converter copies those IDs into SamplingParams.logprob_token_ids without the Python-side 128-ID cap, vocabulary check, or logprobs-count consistency check, so the V1 GPU logprob sampler raises a fatal exception after execution begins. Only deployments exposing the Rust gRPC path on the vulnerable V1 sampler are affected; no public exploit identified at time of analysis, and the vuln.today priority is this_week.
An unauthenticated remote attacker who can reach the Rust gRPC Generate/GenerateStream frontend of vLLM 0.22.0 through 0.23.x can send a single small request that sets output_candidates.top_n or prompt_candidates.top_n above the server's configured max_logprobs cap - or to a value such as 2,147,483,648 that wraps negative when the protobuf uint32 is cast to i32 - and the unchecked count is forwarded into the V1 sampler's torch.topk call, terminating EngineCore and taking the inference service down for that request. The flaw is a missing validation and checked-conversion step in the Rust gRPC converter, which does not replicate the max_logprobs and negative-count guards that the Python SamplingParams validator already enforces; deployments that only expose the Python or OpenAI-compatible API are not reachable through this vector. Impact is availability only - no code execution, data access or model compromise is claimed - and no public exploit code or active exploitation has been identified at time of analysis; a fixed release (0.24.0) is available.
Remote unauthenticated memory exhaustion in vLLM 0.7.3 through versions before 0.31.0 allows clients to terminate shared multimodal inference servers by supplying oversized per-request mm_processor_kwargs, such as large image sizes, patch counts, crop counts, or frame counts, to processors including Isaac, InternVL, and H2OVL. Deployments are exposed when they serve a multimodal model and accept client-controlled mm_processor_kwargs without validation; text-only models and hardened configurations that disable or clamp these parameters are not affected. No public exploit was identified at time of analysis, and the impact is availability-only, with the highest practical risk for multi-tenant or internet-exposed inference APIs.
Cache aliasing in vLLM before 0.31.0 allows authenticated users of a shared deployment to receive another request's cached processed media or reuse first-block KV cache state by supplying colliding EXIF ImageID or cache_salt values. The flaw is only exploitable when image-processing and/or prefix-KV caches are shared across distinct callers or tenants and the attacker can control the relevant cache-key inputs; single-tenant or isolated-cache deployments have no cross-request target. No public exploit identified at time of analysis; the vendor CVSS 4.0 score is 7.1, and the independent assessment rates confidentiality impact high with limited integrity impact.
Remote code execution in vLLM 0.7.3 through 0.30.x lets remote, unauthenticated clients run arbitrary Python inside the API server process when a multimodal request to the /tokenize endpoint supplies a crafted mm_processor_kwargs.code_revision value, which vLLM forwards to Transformers AutoProcessor.from_pretrained and uses to select which revision of the model repository's dynamic processor code gets imported. Exploitation requires two non-default preconditions: the server must be running with trust_remote_code enabled, and the attacker must control (or be able to write) a revision in the model repository being served, so default hardened deployments with remote code disabled are not exposed. No public exploit code or confirmed active exploitation was identified at time of analysis, but the impact for exposed configurations is full confidentiality, integrity and availability loss (vendor CVSS 4.0 score 9.2; our independent CVSS 3.1 assessment of 8.1 reflects the high attack complexity created by the prerequisites).
Unauthenticated memory exhaustion in vLLM versions after 0.24.0 and before 0.31.0 can crash the API process when the MOSS-Audio model is served, because request-controlled mm_processor_kwargs values are cached in an unbounded dictionary. Attackers can send distinct or oversized mel_config values to the /tokenize endpoint, which bypasses --api-key authentication, steadily consuming host memory until the service dies. No public exploit identified at time of analysis; the vendor-released fix is vLLM 0.31.0, and only deployments actively serving MOSS-Audio with a reachable /tokenize endpoint are exposed.
Crafted /inference/v1/generate requests can permanently stall vLLM before 0.31.0 by killing the EngineCore input thread with an uncaught VLLMValidationError while /health continues to return 200. The trigger is a generate request that sets max_tokens to null-causing the min_tokens <= max_tokens validation to be skipped-together with an oversized min_tokens value, after which all subsequent generation requests hang until a manual restart. This is an availability-only flaw (CWE-248); the supplied CVSS 4.0 vector scores it 7.1 with PR:L, while our independent assessment uses CVSS 3.1 with PR:N, so authentication or network ACLs in front of the inference API materially reduce exposure, and no public exploit identified at time of analysis.
Denial of service in vLLM before 0.31.0 allows remote attackers to crash the entire serving instance by forging or reusing a client-supplied multimodal UUID so the P0/P1 processor caches disagree on token placeholders and hit a fatal mismatch. The flaw is reachable only when the deployment serves a multimodal model and exposes the multimodal inference API; text-only vLLM deployments are not affected. No public exploit was identified at time of analysis, and authentication requirements are conflicting in the supplied data: the CVSS 4.0 vector is PR:L while the independent assessment uses PR:N and the description says unauthenticated, so exposure depends on whether the endpoint is protected (vLLM's default server has no authentication per the assessment).
Heap corruption and process crash in vLLM audio transcription allow an authenticated remote attacker to repeatedly deny service to the inference API in versions before 0.29.0. Uploads to /v1/audio/transcriptions that fail primary decoding fall through to a PyAV/FFmpeg av.open() fallback guarded only by a file-size check, so a malformed IAMF container reaches FFmpeg's vulnerable IAMF parser and corrupts the heap, terminating the API process. The CVSS vector (PR:L) confirms authentication is required, impact is availability-only (no confidentiality or integrity effect), and no public exploit code or CISA KEV listing was identified at time of analysis; no EPSS score was supplied.
Denial of service in vLLM before 0.29.0 allows an authenticated API user to permanently disrupt the inference service with a single malformed request to the OpenAI-compatible POST /v1/completions or POST /v1/chat/completions endpoints. The server accepts user-supplied stop_token_ids and checks only that they are integers, not that they fall within the model's vocabulary/logits range; when min_tokens > 0 those ids are used as logits indices to suppress stop tokens, so an out-of-range value reaches a CUDA index_put_ operation and trips a device-side assertion that returns HTTP 500 and leaves EngineCore in a fatal state until the service is restarted. The impact is bounded to availability (no code execution or data disclosure) and exploitation requires valid API credentials plus exposure of the OpenAI-compatible endpoints; no public exploit code was identified at time of analysis, and the vendor has released a fix.
Pinned vLLM deployments (0.22.1 through 0.28.0) running the FunAudioChat or Tarsier2 architectures silently ignore the operator's --revision/--code-revision pin for several Hugging Face artifacts, allowing a subsequent change to the upstream repository's default branch to alter audio preprocessing, speech-tokenizer behavior, or Tarsier2 configuration without any change to the operator's configured pin. The result is a supply-chain integrity and reproducibility failure rather than a code-execution flaw: the advisory explicitly states it is residual to CVE-2026-47155 / GHSA-3ww4-5jv9-j5gm and does not constitute remote code execution or a trust_remote_code=False bypass, despite an 'RCE' tag appearing in some threat-feed metadata. There is no public exploit code identified at time of analysis and no confirmed active exploitation (CISA KEV); exploitation requires the narrow combination of an affected architecture, an operator using a revision pin, and an actor able to modify the upstream Hugging Face repository's default revision, so default general-purpose vLLM deployments are unaffected.
Out-of-vocabulary stop_token_ids in vLLM 0.22.0 through 0.23.0 cause a CUDA tensor indexing failure that drives EngineCore into a fatal state and forces a manual service restart. The trigger is a generation request that simultaneously sets min_tokens greater than zero and includes stop_token_ids outside the model's vocabulary bounds, slipping past missing validation in the Rust HTTP and gRPC frontends to reach MinTokensLogitsProcessor; CVSS 4.0 scores this 8.2, but the assessed impact is availability-only (C:N/I:N/A:H) and deployments enabling vLLM's optional API-key authentication would require a valid key, so real-world severity is lower than the headline score. No public exploit code or confirmed active exploitation is identified at time of analysis (not in CISA KEV), and a vendor patch is available per advisory GHSA-qff2-492f-9fm4, with ENISA EUVD-2026-87746 recording the affected range as 0.22.0 up to but not including 0.24.0.
Denial of service in vLLM deployments running versions before 0.29.0: an attacker with low-privilege access to the disaggregated serving endpoint /inference/v1/generate can submit an overlong token_ids list accompanied by a 'features' (multimodal) payload, bypassing prompt-length validation and causing a worker failure that takes down inference capacity. The issue is availability-only (no confidentiality or integrity impact) and is reachable over the network without user interaction, but exploitation requires that the deployment run in non-default disaggregated serving mode with a multimodal model whose processor reports skip_prompt_length_check=True (Nemotron Parse, Whisper, or FireRedLID), so standard single-node text-only vLLM installations are not exposed. Vendor-released patch: 0.29.0; no public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV.
Pre-inference resource exhaustion in vLLM up to and including 0.29.0 lets remote attackers force the API server or batch runner to fully download, base64-decode and materialize attacker-controlled media before the documented VLLM_MAX_AUDIO_CLIP_FILESIZE_MB compressed-audio cap (25 MB default) and the per-modality --limit-mm-per-prompt item limits are enforced. Four ingress paths are affected - the shared media-acquisition layer (HTTPConnection.get_bytes()/async_get_bytes()), the chat completions audio_url/base64 path, the batch speech runner, and the Rust frontend POST /tokenize route - with the /tokenize path unauthenticated by design and the chat/batch surfaces gated only when an API key is actually configured, so an attacker can allocate memory and consume outbound bandwidth proportional to an attacker-chosen body size or media-item count. Impact is availability-only (no code execution or data disclosure); the vendor CVSS 4.0 vector scores 7.1 with PR:L, while the independent assessment scores it 7.5 under CVSS 3.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) to reflect the unauthenticated /tokenize path, and no public exploit code was identified at time of analysis.
Denial of service in vLLM before 0.28.0 allows an unauthenticated remote attacker to poison the process's GPU context by sending a single request containing a negative token ID to the /v1/embeddings or /pooling endpoints, after which all subsequent inference requests fail until the server is restarted. The vulnerable endpoints are part of vLLM's OpenAI-compatible HTTP server and ship enabled in default configurations, and because vLLM provides no built-in authentication, the practical risk is governed entirely by whether the API is reachable by untrusted clients over a public or shared network. Impact is availability-only (assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H; vendor CVSS 8.7), no public exploit code was identified at time of analysis, and no KEV-listed active exploitation is reported.
Uncontrolled memory allocation in vLLM's transcription endpoint before 0.28.0 allows authenticated API clients to crash the entire server process by submitting FLAC audio files with forged, inflated sample rate headers. Because vLLM commonly operates as a shared API server across multiple tenants, a single authenticated attacker can deny service to all concurrent users. VulnCheck reported this with a CVSS 4.0 score of 7.1; no public exploit code or CISA KEV listing has been identified at time of analysis.
Remote code execution in vLLM's LlavaOnevision2 processor loader allows an attacker who controls a model repository to execute arbitrary code on systems that load that model, bypassing the trust_remote_code=False safety parameter entirely. All vLLM installations prior to version 0.28.0 are affected when loading LlavaOnevision2-architecture models; the security control that operators rely on to safely evaluate third-party models is silently non-functional for this processor class. No public exploit code has been identified and the vulnerability is not listed in CISA KEV, but the attack requires only the ability to publish a model to an accessible registry and social-engineer a user into loading it.
Denial of service in vLLM 0.12.0 through 0.23.x lets any authorized API caller crash the entire inference server by submitting a pure prompt-embeddings payload to the /v1/completions endpoint when a model using M-RoPE (multimodal rotary position embedding) is loaded. The malformed request trips a reachable assertion in the EngineCore process, which terminates the whole server rather than rejecting the single request. There is no public exploit identified at time of analysis and it is not listed in CISA KEV; the flaw is fixed in vLLM 0.24.0.
Denial of service in vLLM inference servers prior to 0.24.0 allows remote unauthenticated attackers to hang an inference worker indefinitely by submitting a single request with an adversarial regular expression via the structured_outputs.regex API parameter. The pattern is passed to grammar compiler backends (xgrammar with no guard, outlines with structural-but-not-complexity validation) where nested quantifiers trigger exponential state-space expansion (ReDoS). No public exploit identified at time of analysis, though the trivial request-based trigger makes weaponization straightforward.
Denial of service in the vLLM LLM inference server (all versions prior to 0.24.0) allows a remote client to crash the shared engine worker by sending a specific multi-request speculative decoding workload. The rejection sampler produces a recovered token equal to the vocabulary-size boundary, which is coerced to -1, written back into the drafter's input ids, and later dereferenced by the embedding/attention path, triggering a GPU device-side assertion that kills the worker. There is no public exploit identified at time of analysis and this CVE is not in CISA KEV; per CVSS the impact is availability-only (C:N/I:N/A:H) with a low EPSS profile expected for a crash-only bug.
Remote code execution in vLLM versions prior to 0.22.1 allows attackers to backdoor production LLM inference deployments through a dependency confusion attack in the project's Dockerfile. Because flashinfer-jit-cache was pulled via --extra-index-url with UV_INDEX_STRATEGY=unsafe-best-match while the name remained unregistered on PyPI, any attacker who claimed the name on PyPI with a higher version would have their code executed as root during every Docker build. No public exploit identified at time of analysis, but the supply-chain primitive is well understood and trivially weaponizable.
Denial of service in vLLM 0.8.0 and later allows remote unauthenticated attackers to crash the inference server by sending a single OpenAI-compatible chat completion request containing a video/jpeg data URL with thousands of comma-separated base64-encoded JPEG frames. The VideoMediaIO.load_base64() method decodes every frame without enforcing a count limit, exhausting server memory. No public exploit identified at time of analysis, but an upstream fix commit is available on GitHub.
Remote code execution in vLLM 0.14.1 occurs because `trust_remote_code=True` is hardcoded inside the NemotronVL and KimiK25 model loaders, silently overriding the operator's explicit `--trust-remote-code=False` safety flag. Any deployment that loads a malicious or compromised HuggingFace repository for these model architectures will execute attacker-controlled Python in the inference process, despite UI:R requiring an operator to initiate the model load. No public exploit is identified at time of analysis, but the issue is an incomplete fix for CVE-2025-66448 and CVE-2026-22807, indicating the regression pattern is already well understood.
vLLM versions 0.5.5 through 0.17.x use incorrect mono audio downmixing via numpy.mean instead of the ITU-R BS.775-4 weighted standard, causing audio processed by AI models to diverge from human perception. An authenticated remote attacker with low privileges can exploit this inconsistency to manipulate audio-based model outputs or infer mismatches between expected and actual audio processing, affecting integrity of audio-driven inference pipelines. The vulnerability has been patched in vLLM 0.18.0.
CPU and memory exhaustion in vLLM's /v1/responses endpoint affects versions 0.16.0 up to (but not including) 0.32.0, where an authenticated caller can inject a request-level Jinja chat template that bypasses the `trust_request_chat_template` policy gate. Only availability is impacted (no confidentiality or integrity loss), and exposure is limited to servers started with the documented default `trust_request_chat_template=False` and no explicit `--chat-template`, since that is the configuration in which the request-supplied `chat_template` key survives into the renderer. No public exploit code and no CISA KEV entry were identified at time of analysis, and the vendor's advisory rates the issue as Moderate.
vLLM's OpenAI-compatible server before 0.32.0 registers Starlette CORSMiddleware with allowed_origins defaulting to ["*"], so a malicious web page loaded by a victim can issue cross-origin requests to a vLLM server the browser can reach and read the responses. When no --api-key or VLLM_API_KEY is configured - the default - endpoints such as GET /v1/models and POST /v1/chat/completions are reachable, letting the page enumerate models, drive chat completions, burn GPU time, and read model output through the victim's browser; if a key is set, the guarded prefixes require that the caller already hold a usable token. Cookie-based CSRF does not apply because allow_credentials is False by default, and exploitation needs user interaction plus a browser-reachable server, which is why this scores only 3.4 and is tracked as monitor priority; no public exploit code was identified at time of analysis.
Out-of-vocabulary token IDs slip past vLLM's prompt validation and can crash the inference engine, turning a single malformed request into a denial of service. Releases prior to 0.32.0 derive max_token_id from the tokenizer's vocabulary count rather than the largest valid index, so a pre-tokenized prompt carrying the ID equal to the vocabulary size is accepted and reaches the embedding lookup one row out of range, raising a CUDA device-side assert that poisons the context and terminates the engine. The crash is confined to models whose vocabulary is an exact multiple of the 64-row embedding padding size (Llama-2-family, vocab 32000) served at tensor-parallel size 1; the assessed CVSS 3.1 score is 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), reflecting that low-privilege API access is needed and that availability is the only impacted property, and no public exploit was identified at time of analysis.
Denial of service in vLLM: any deployment serving the DeepSeek-OCR model family (deepseek-ai/DeepSeek-OCR, DeepSeek-OCR-2, or baidu/Unlimited-OCR) can be permanently killed by a single schema-valid chat request containing an ordinary half-black/half-white 1024x1024 PNG, whose pixel values cancel to exactly zero after normalization. That zero sum makes the image parser return no embedding, which trips a fatal encoder-output assertion inside the EngineCore worker; the API server raises EngineDeadError and exits, taking down every in-flight and future request until a manual restart. Affected versions run from 0.11.1 through before 0.32.0 on default configuration, the vendor advisory documents a verified end-to-end reproduction, but there is no CISA KEV listing and no public exploit code identified at time of analysis; the priority rating places remediation in the this-month window rather than emergency response.
Denial of service in vLLM prior to 0.32.0 lets a remote client terminate the entire inference engine by submitting a single legal audio clip - a roughly 10-minute silent recording is enough, no crafted content required. When the server hosts microsoft/Phi-4-multimodal-instruct (or another model reusing its audio tower), the Phi-4 conformer encoder runs attention in eager mode by default, materializes a full attention probability matrix per layer for every 500-frame chunk, and retains it on the module, so GPU memory climbs monotonically within one request until a CUDA out-of-memory error kills EngineCore for all users; the advisory reports worker death in about six seconds and the API then returns EngineDeadError. No public exploit code was identified at time of analysis and the issue is not in CISA KEV; the authoritative assessment rates this a genuine but moderate-priority availability issue, rated high on availability only (C:N/I:N/A:H) and unauthenticated where the API is exposed, while deployments not serving this audio-capable model are unaffected.
Denial of service in vLLM 0.19.0 through 0.31.x lets a caller who holds a valid API credential hand the server a hostile Jinja2 chat template - either directly in the request when the operator has not set --chat-template, or indirectly through a model repository whose tokenizer_config.json carries one - and hang every chat-style endpoint on that API-server replica until the process is restarted. The render runs inside a sandboxed Jinja environment with no wall-clock timeout, no output-size cap and no loop or binop bound, on a render pool that defaults to a single non-interruptible worker, so a tiny non-terminating template wedges /v1/chat/completions, /v1/responses, /tokenize and the chat pooling/invocations paths for all tenants, while a string-multiplication variant instead OOM-kills the process. Impact is availability-only across tenants of one replica (CVSS:3.1 6.5, PR:L), Harmony/gpt_oss models skip the affected Jinja path, and no public exploit code was identified at time of analysis; the vendor shipped a fix in 0.32.0.
Concurrent constrained-decoding traffic against vLLM servers running versions before 0.31.0 can leave a stale token allowlist in a recycled batch slot, so a victim's unrestricted generation request is silently constrained to the attacker's token set. The flaw is in InputBatch.condense(), which recycles finished request slots without clearing allowed_token_ids; remote unauthenticated attackers who can reach the generation API, including the unauthenticated /invocations endpoint, can trigger it by submitting many concurrent constrained requests while a race with slot reuse is won. Impact is integrity-only - the victim's output is degraded or steered, but no victim data is read - and success is timing- and load-dependent (CVSS AC:H with attack requirement AT:P). No public exploit code or confirmed active exploitation has been identified at time of analysis, and the issue is fixed in vLLM 0.31.0.
Denial of service in vLLM up to and including 0.31.0 lets a remote, authenticated user who can submit inference requests crash the serving engine by combining a prompt_embeds input with token penalty parameters (frequency, presence, or repetition), a combination that drives get_token_bin_counts_and_mask in vllm/model_executor/layers/utils.py into a fault. Publicly available exploit code exists in the form of a published reproduction script, and the vendor had not responded to the early issue report at the time of analysis, so unpatched, internet-exposed or multi-tenant deployments that accept such requests are exposed to availability loss. Impact is limited to availability of the serving process - no data disclosure or integrity compromise has been demonstrated.
An out-of-bounds read in vLLM up to and including version 0.31.0 lets a caller with low-privilege access to the completions API drive the SSM convolution path past the end of a buffer, degrading availability of the inference worker. The flaw is confined to deployments that serve Mamba/Mamba2-architecture models, because it lives in conv_ssm_forward of vllm/model_executor/layers/mamba/mamba_mixer2.py; instances running only standard transformer models are unlikely to reach the vulnerable code. Publicly available exploit code exists, but there is no confirmed active exploitation (not listed in CISA KEV); the independent assessment bounds impact to low availability loss with no confidentiality or integrity effect, making this a moderate rather than top-tier priority.
Malformed cache_salt values submitted to vLLM's OpenAI-compatible inference endpoints can crash the EngineCore process and deny service to every concurrent user on deployments configured with the LMCache-MP connector. Only vLLM releases prior to 0.30.0 are affected, and exploitation requires low-privilege API access (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, base score 6.5) plus the non-default LMCache-MP connector; a cache_salt containing '@', '/', '\\', or NUL, or longer than 128 characters, raises an uncaught ValueError during scheduler cache lookup. The flaw is fixed in version 0.30.0, and no public exploit code or confirmed active exploitation was identified at time of analysis, making this a genuine but moderate-priority availability issue rather than a high-severity emergency.
vLLM versions prior to 0.30.0 derive the flash late-interaction query-cache key from the caller-controlled X-Request-Id header, so an authenticated API caller on a shared deployment can collide with a victim's in-flight request and cause the victim's documents to be scored against the attacker's query through the /score and /rerank endpoints, while shared use counters can also give rise to a late-interaction cache-miss error. The assessed vector is CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:L (base 4.2), reflecting a narrow concurrency race that requires knowledge of or a lucky guess at the victim's request identifier, and no confidentiality impact; there is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV). The issue is fixed in vLLM 0.30.0, and the practical risk is confined to multi-tenant or otherwise shared deployments that actually enable the flash late-interaction scoring path.
Improper input validation in vLLM's disaggregated scale-out (token-in-token-out) serving path lets an authenticated low-privilege remote caller send forged multimodal request fields to the /inference/v1/generate endpoint and terminate the shared EngineCore process. Affected are vLLM releases prior to 0.30.0 that are explicitly deployed in the disaggregated scale-out mode; attacks on the cache variant additionally require the attacker to know or induce a victim's content hash so that forged cache identifiers (mm_hashes) match, enabling cross-request encoder-cache poisoning or retrieval and, in the same input-validation failure, corrupted replayed transport semantics from dropped sparse placeholder masks. Both confidentiality and integrity impact are therefore low-severity and preconditional, while availability impact on the shared engine is high; the CVSS 3.1 vector is AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Multimodal inference requests to vLLM deployments running versions prior to 0.28.0 can trigger a process-level assertion failure that takes down the shared serving engine, denying service to all concurrent users. The flaw is a state desynchronization in the default mirrored multimodal LRU cache: a media hash can be committed in the frontend MultiModalProcessorSenderCache during rendering before engine admission, but if the request is rejected, the engine-side MultiModalReceiverCache never stores the corresponding payload, so any later request reusing that hash reaches an assertion reading "Expected a cached item." Exploitation requires only the ability to submit requests to the service (PR:L, network-reachable, no user interaction), is confined to deployments serving multimodal models, and results in availability impact only; no public exploit code was identified at time of analysis and upgrading to 0.28.0 removes the issue.
vLLM deployments prior to 0.30.0 with prefix caching enabled (the default) fail to carry the caller's cache_salt value across Harmony tool continuations submitted to "POST /v1/responses", so continuation prefixes land in the global unsalted prefix-cache namespace. This lets an authenticated tenant who can reconstruct a victim's low-entropy post-tool conversation history submit the same continuation and read the cached_tokens_per_turn counter as a hit/miss oracle, confirming whether that prefix was previously processed and thereby defeating salt-based tenant isolation of the cache. This is a genuine but low-severity, low-priority issue: the assessed vector is CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N, exploitation requires authenticated access, prefix caching to be on, cache_salt salting to be in use, and the victim's history to be low-entropy and reconstructable, and only the isolation property leaks - no direct model output or prompt content is disclosed. No public exploit code and no confirmed active exploitation were identified at time of analysis.
Denial of service in vLLM through 0.26.0 lets remote attackers crash or exhaust inference workers by submitting inputs containing deeply nested '{...}' or '[...]' delimiter structures that the Gemma4UnifiedParser expands recursively without any depth bound, exhausting the thread stack. The flaw is confined to the Rust parser component (rust/src/parser/src/unified/gemma4.rs) and only affects deployments that route requests or model output through the Gemma4 unified parser - typically Gemma-family model serving with tool-calling or structured-output parsing. Publicly available exploit code exists (a published GitHub gist demonstrates the nested-input trigger), and the vendor has released a fix in v0.29.1rc0 via PR #54303; no CISA KEV listing or confirmed in-the-wild exploitation was provided in the source data. Impact is availability-only (no data disclosure, no code execution), and the CVSS 4.0 vector scores it 6.9 with E:P while the independent assessment rates it CVSS 3.1 A:H.
Unauthenticated remote attackers can exhaust GPU memory on vLLM deployments before 0.29.0 that accept video inputs, by requesting different sampler subclasses whose decoder-allocation counters increment independently and thus sidestep the shared PyNvVideoCodec decoder limit. The result is availability degradation (GPU memory exhaustion) rather than data disclosure or code execution, and success is not deterministic - it depends on repeated requests that win allocation and timing conditions (AC:H, AT:P), with additional practical constraints where the API is gated by an API key or network gateway. No public exploit code has been identified and the issue is not confirmed as actively exploited (CISA KEV); a vendor patch is available per the upstream GitHub security advisory.
Remote denial of service in vLLM versions before 0.29.0 allows unauthenticated clients to bypass the configured multimodal audio clip size limit (VLLM_MAX_AUDIO_CLIP_FILESIZE_MB) by submitting oversized audio through chat endpoints, causing excessive memory and CPU consumption during decoding. The CVSS vector confirms this is remotely reachable with no privileges (PR:N) and no user interaction, but impact is availability-only (VA:L) - there is no data exposure, integrity loss, or code execution. No public exploit code has been identified at time of analysis, and a vendor-released patch (0.29.0) is available, making this a genuine but low-severity resource-exhaustion issue rather than a high-impact breakout. Exploitability in practice depends on whether the audio-capable chat endpoint is exposed without an authenticating reverse proxy, request-size limits, or rate limiting, and on the host's memory/CPU headroom.
Denial of service in vLLM releases before 0.29.0 allows unauthenticated remote attackers to stall the single EngineCore scheduler thread by sending HTTP requests with multi-hundred-megabyte cache_salt values to the OpenAI-compatible or Anthropic-compatible API endpoints. The oversized salt value is pickle-serialized and SHA-256 hashed on the scheduler thread, so a single request blocks scheduling and inference for all concurrent requests, degrading or halting service. No public exploit code was identified at time of analysis and the issue is not in CISA KEV, so real-world risk is concentrated on internet-facing or multi-tenant vLLM deployments that expose these endpoints without an authenticating gateway or upstream request-size limits.
Out-of-bounds bad_words token indices in vLLM through 0.29.0 are not validated against the model's generation output width, allowing the indices to be written past the logits buffer and corrupt the sampling state of concurrently batched requests, so unrelated in-flight HTTP requests can receive incorrect output tokens. Exploitation requires API access sufficient to submit sampling requests with a bad_words parameter (authenticated, PR:L), a target model whose tokenizer exposes input-only placeholder tokens with IDs above the model's logits vocabulary (typically multimodal models such as those with <|audio|> tokens), and concurrent requests sharing the batch, so a text-only model whose tokenizer vocabulary equals its output vocabulary is not affected. No public exploit code has been identified at time of analysis and there is no KEV listing; the issue is a low-severity integrity/quality-of-output defect rather than a confidentiality or availability compromise, and an upstream fix is available as a pull request.
Out-of-bounds writes in the Triton bincount sampling kernel of vLLM through 0.29.0 let unauthenticated remote clients corrupt a neighboring request's repetition-penalty state by submitting multimodal audio input that contains a token ID equal to the model's vocabulary size. The root cause is an unvalidated array index (CWE-129): prompt and output token IDs are used to index the penalty prompt-presence bitset and output bin counts without any bounds check against vocab_size, so a one-past-the-end token spills into the adjacent request's mask/count rows. Impact is integrity-only and confined to altered repetition-penalty behavior for concurrently served requests - there is no code execution, data disclosure, or denial of service - and exploitation requires a CUDA GPU with compute capability >= 8.0, a multimodal model accepting audio tokens, and concurrent traffic in a shared, multi-tenant deployment; no public exploit code and no confirmed active exploitation have been identified at time of analysis.
Sampling-parameter validation in vLLM before 0.29.0 checks the allowed_token_ids allowlist against the tokenizer vocabulary size instead of the model's output logits width, so a remote client calling the OpenAI-compatible inference API can supply token IDs that are valid for the tokenizer but out of range for the model output (the advisory's cited case is a multimodal model with 128257 tokenizer tokens versus 128256 output logits). Those out-of-range IDs pass validation and reach the GPU sampling path, where LogitBiasState's Triton logit-bias kernel indexes past the valid logits row and corrupts shared GPU logits state, causing concurrent victim requests in the same batch to sample tokens outside their own allowlists. The impact is limited to sampling-constraint integrity (no data disclosure, crash, or code execution) in shared or multi-tenant deployments, and it is inert on models whose tokenizer and output vocabularies are the same size; there is no public exploit identified at time of analysis and no confirmed active exploitation (not listed in CISA KEV).
GPU memory exhaustion in vLLM versions prior to 0.28.0 lets an attacker with low-privileged API access (PR:L in the CVSS vector) force the server to load the PyNvVideoCodec hardware video decoder on demand by setting media_io_kwargs.video.video_backend to 'pynvvideocodec' in a Chat Completions or Responses request, even when the operator configured a software decoder at startup. Because the engine budgets decoder VRAM only from static configuration, the request-selected backend allocates a CUDA context, decoder surfaces, and decoded-frame buffers that were never deducted from the KV-cache budget, so repeated video requests can exhaust shared GPU memory and cause request failures, worker crashes, and denial of service. The issue is availability-only (C:N/I:N/A:H) and exploitable only on video-capable GPU deployments running a video-accepting model with PyNvVideoCodec actually installed; vLLM 0.28.0 and later are not affected. No public exploit code was identified at time of analysis and the flaw is not confirmed actively exploited (CISA KEV), though the upstream fix commits and PR are publicly visible.
Out-of-memory worker crashes in vLLM can be induced by a single small compressed audio payload submitted to the /v1/chat/completions input_audio path, because that code path decodes audio without the VLLM_MAX_AUDIO_DECODE_DURATION_S guard already enforced on /v1/audio/transcriptions - an unbounded resource allocation flaw (CWE-770) that expands a tiny compressed file into a very large float32 PCM buffer. The issue affects every vLLM release prior to 0.24.0 that serves an audio-capable model and exposes the chat completions endpoint, with inline data URLs additionally escaping VLLM_AUDIO_FETCH_TIMEOUT; impact is availability-only (no confidentiality or integrity loss). Per the assessed vector the attack is remote and unauthenticated (PR:N, UI:N), while the vendor-published vector scores it PR:L, so whether any front-of-service authentication gate exists is deployment-specific; at time of analysis no public exploit code and no confirmed active exploitation were identified, and a vendor patch exists in 0.24.0.
Inefficient algorithmic complexity (CWE-407) in vLLM up to and including 0.29.0 causes the thinking-budget marker search in vllm/v1/sample/thinking_budget_state.py to re-scan an ever-growing output token buffer on every decode step, degrading throughput and consuming CPU when serving reasoning-capable models. An authenticated API client (CVSS 4.0 vector lists PR:L) that sets the thinking_token_budget sampling parameter can trigger the quadratic blowup, but only when the generated output never contains the configured reasoning start/end marker token sequences, so the internal search cursors fail to advance; the practical worst case is partial availability loss (slowed or stalled generation per affected request) rather than a crash, code execution, or any confidentiality/integrity impact. This is a low-severity availability issue - no public exploit code has been identified at time of analysis and there is no CISA KEV listing - and the vendor score of 5.3 is well calibrated to the assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L. Upstream fix is available as GitHub PR vllm-project/vllm#51133, which awaits acceptance, so no released patched version is independently confirmed.
Unbounded buffering of unacknowledged KV-transfer acknowledgements in the MoRIIO connector of vLLM 0.26.0 and 0.27.0 allows a remote, unauthenticated client to grow worker memory indefinitely and degrade or crash LLM inference serving. The root cause is CWE-400 uncontrolled resource consumption in moriio_connector.py, where acknowledgements whose transfer mapping is not yet populated are appended to _pending_unmapped_acks with no TTL or size cap across request_finished, get_finished and _handle_release_message. Impact is availability-only (CVSS 4.0 base 6.9, AV:N/AC:L/PR:N/UI:N/VA:L); no public exploit code and no CISA KEV
A resource-exhaustion (denial of service) flaw in vLLM's OpenAI-compatible /v1/chat/completions endpoint lets a caller- or model-supplied Jinja chat_template drive nested range() loops whose evaluation cost grows as O(N^depth), tying up a request-runtime worker thread for tens of seconds. vLLM releases up to and including 0.27.1 are affected (EUVD lists 0.27.0 and 0.27.1), with the CPE range expressed as vllm-project:vllm:* so earlier releases are plausibly in scope too. Publicly available exploit code exists, and CVSS 4.0 rates the issue only 2.1 with availability impact rated Low; a fix PR that introduces a minijinja evaluation 'fuel' budget is still awaiting acceptance.
Denial-of-service in vLLM's Rust-based tiktoken tokenizer allows a local low-privileged attacker to crash the vLLM process by supplying a crafted vocab file containing duplicate token ranks. The TiktokenTokenizer::new() function in the Rust tokenizer backend previously panicked unconditionally when parsing a tiktoken file with two tokens sharing the same rank value, rather than returning a graceful error. A public proof-of-concept exploit is available via GitHub Gist; no patch has been merged as the fixing pull request remains open.
Unbounded audio extraction in vLLM 0.10.2-0.27.x enables remote denial of service against NanoNemotronVL model deployments. The root cause is an asymmetric protection gap: `_extract_audio_from_videos` in `nano_nemotron_vl.py` calls `load_audio_pyav` without the size or duration guard parameters enforced on the direct audio upload path, bypassing the `VLLM_MAX_AUDIO_DECODE_DURATION_S` and `VLLM_MAX_AUDIO_DECODE_BYTES` environment variable limits entirely. An attacker submitting a maliciously compressed video via the multimodal inference API forces the server to allocate gigabytes of memory during audio decoding, crashing the service. No public exploit code or CISA KEV listing has been identified at time of analysis; vendor-released patch is available in vLLM 0.28.0.
Remote denial-of-service in vLLM before 0.27.0 allows unauthenticated network attackers to activate the DeepStream GPU video-decode backend per-request, initialize the process-wide GPU decode pool, and submit video content that bypasses pixel-limit enforcement, causing partial availability loss for concurrent inference requests. The root cause is vLLM's failure to classify DeepStream as a GPU backend subject to resource controls combined with an omitted pixel-limit check in the DeepStream decode path (CWE-400). No public exploit code has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog.
Server-side request forgery in vLLM's MiMoV2OmniMultiModalProcessor allows authenticated API users to bypass the framework's media access controls, enabling arbitrary file reads on the vLLM host and SSRF requests to internal network resources. The flaw affects all vLLM releases prior to 0.26.0 where attacker-controlled image and audio URL strings were passed directly to _fetch_image, requests.get, and Image.open instead of routing through the MediaConnector abstraction that enforces allowed_media_domains and allowed_local_media_path restrictions. No public exploit code or CISA KEV listing exists at time of analysis, but the low attack complexity and network-accessible vector make this a meaningful risk for deployments serving untrusted authenticated users via the affected multimodal processor.
Uncontrolled resource consumption in vLLM's OpenAI-compatible completions endpoint allows any authenticated API client to exhaust CPU, memory, async scheduling capacity, and engine request slots with a single crafted request. Affected versions span 0.19.0 through 0.25.x; the issue is fixed in 0.26.0. No public exploit code has been identified and CISA has not listed this in KEV, but the attack is trivially constructable by any client with a valid API credential.
Cross-user inference data leakage in vLLM prior to 0.27.0 exposes one batched user's prompt or completion output to another user sharing the same GPU inference batch. The root cause is a 32-bit integer overflow in the CUDA kernel `act_and_mul_kernel` within `activation_kernels.cu`, where the pointer arithmetic `blockIdx.x * 2 * d` wraps around when token indices and hidden-dimension sizes are large enough, redirecting the kernel to read from an adjacent user's input buffer. No active exploitation has been confirmed (no CISA KEV listing), but the vendor has patched the issue in v0.27.0 and a detailed GitHub advisory and PR diff are publicly available.
Race condition in vLLM's prompt embedding loader allows concurrent API requests to bypass the sparse tensor invariant guard introduced for CVE-2025-62164, permitting an invalid sparse tensor to reach `tensor.to_dense()` and cause availability disruption. Affected deployments span versions 0.20.2rc0 through 0.25.x and are limited to instances with `enable_prompt_embeds` explicitly enabled. No public exploit code or CISA KEV listing exists at time of analysis; the fix is confirmed in v0.26.0.
Uncontrolled resource consumption in vLLM's lm-format-enforcer structured output backend (all versions prior to 0.26.0) enables unauthenticated remote denial of service via the /v1/completions API endpoint. By submitting a crafted catastrophically backtracking regular expression to the structured_outputs.regex parameter, a remote attacker can saturate an entire CPU core and stall the structured-output engine path indefinitely - blocking inference requests that rely on the lm-format-enforcer backend for all concurrent users. No public exploit code has been identified and the vulnerability is not listed in CISA KEV, though the attack primitive (ReDoS against an exposed API) is well-understood and trivially constructible by any attacker familiar with catastrophic regex patterns.
Information disclosure in vLLM prior to version 0.26.0 leaks server filesystem internals - including OS usernames, home and virtual-environment directory paths, Python version, internal package structure, line numbers, and endpoint handler names - through HTTP error responses. Any unauthenticated network attacker can trigger this by sending malformed JSON to the OpenAI-compatible API endpoints, requiring zero privileges and no special configuration beyond a default vLLM deployment. No public exploit code has been identified at time of analysis, and no CISA KEV listing exists; however, the trivial exploitation bar (a single malformed HTTP request) and the reconnaissance value of the leaked data elevate real-world risk above the CVSS 5.3 score alone implies.
Memory exhaustion in vLLM 0.22.0-0.23.0 allows authenticated API callers to crash or destabilize the inference server by uploading arbitrarily large audio files. The `/v1/audio/transcriptions` and `/v1/audio/translations` endpoints invoke `request.file.read()` to fully buffer multipart uploads into process memory before the `VLLM_MAX_AUDIO_CLIP_FILESIZE_MB` size guard is evaluated, meaning the size limit is checked only after the damage is done. No public exploit is identified at time of analysis; vendor-confirmed fix is available in version 0.24.0.
Denial of service in vllm 0.19.0's OpenAI-compatible serving path allows remote unauthenticated attackers to exhaust scheduler resources by submitting requests with unbounded logprob counts. The root cause, confirmed by PR diff analysis, is the absence of any per-batch logprob budget in the v1 scheduler: requests specifying logprobs=-1 (full vocabulary) multiplied across parallel sequences (n) generate massive compute and memory overhead with no cap, blocking or crashing the inference server. Publicly available exploit code exists (GitHub issue #37343); no confirmed active exploitation at time of analysis.
vllm-project vllm version 0.6.0 contains a vulnerability in the AsyncEngineRPCServer() RPC server entrypoints. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
vLLM before 0.32.0 lets untrusted image bytes pick their own Pillow decoder: ImageMediaIO calls Image.open(BytesIO(data)) without an allowlist and the declared MIME label does not constrain format selection, so an EPS payload submitted as image/png is dispatched to the host's Ghostscript. On hosts whose Ghostscript is affected by CVE-2024-29510 this chains to command execution with the vLLM process's privileges, and on environments running Pillow 12.0.0 through 12.2.0 the same boundary reaches CVE-2026-59203, where a malformed EPS parks media-loading workers until the pool is exhausted. The CVSS 3.1 vector is AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H (8.1 High), reflecting that reachability still depends on an image-capable endpoint, the deployment's API-key and network policy, and a vulnerable host dependency; the reported reproduction covered the loader-level command execution, while the HTTP request path was only source-traced. No public exploit code was identified at time of analysis, and CISA KEV does not list this CVE.
Authenticated inference callers on vLLM scale-out deployments that explicitly enable the shared-memory multimodal processor cache (--mm-processor-cache-type shm) can plant forged address and monotonic_id values inside the public features.kwargs_data envelope, causing a worker to dereference attacker-chosen ring-buffer memory and pass those bytes to pickle.loads(), which yields arbitrary Python execution in the worker process. The chain runs over ordinary public HTTP routes (/v1/chat/completions/render, /v1/chat/completions, /inference/v1/generate) and succeeds even with VLLM_ALLOW_INSECURE_SERIALIZATION=0 because it abuses the built-in SHM object deserializer rather than the optional insecure-serialization flag. Exposure is limited to deployments combining a scale-out topology with the non-default SHM cache mode; the flaw is fixed in vLLM 0.32.0, CISA KEV does not list it, and a proof-of-concept chain is described in the upstream advisory but no public working exploit code was confirmed at time of analysis.
Out-of-vocabulary stop_token_ids in vLLM 0.20.1 through 0.28.x allow a client able to submit generation requests to terminate the inference engine, causing denial of service for every other user sharing that server; on the V2 runner the same unchecked index can instead write outside the logits buffer and corrupt adjacent logits or other GPU state. The flaw is an input-validation gap: SamplingParams accepted any integer for stop_token_ids and those values became column indices into the model's logits tensor, so the OpenAI chat and completion paths, the legacy generate endpoint, and batch inputs are all affected. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VA:H) puts this at 7.1 with availability-only impact, and the PR:L metric is the main limiting factor, meaning the attacker needs the privileged capability to submit requests rather than being fully anonymous; no public exploit code or active exploitation has been identified at time of analysis, and priority is this-week remediation rather than emergency response.
Cross-tenant denial of service in vLLM 0.8.5 through 0.31.0 lets one API client crash the shared EngineCore process and drop every co-tenant request on that engine. The crash occurs when a request carrying prompt_logprobs (or echo with logprobs) is issued against a prefix that a KV connector reports as already computed, leaving positions in an uninitialized int32 tensor that the tokenizer then fails to decode, raising OverflowError. Reachability is conditional: the engine must be running the V1 engine with an active KVConnectorBase_V1 subclass returning num_new > 0 (LMCacheConnectorV1, NixlConnector, SharedStorageConnector, P2pNcclConnector, OffloadingConnector, MultiConnector), so plain vLLM without a KV transfer config is not exposed; no public exploit code or CISA KEV entry was identified at time of analysis, and the vendor advisory provides a patch.
Memory exhaustion in vLLM 0.18.0 through 0.30.x lets a client crash or OOM-kill the serving frontend by setting media_io_kwargs.video.num_frames to -1 (or an arbitrarily large positive value) alongside a large inline video/jpeg payload, so the API decodes and stacks every frame. Only deployments serving a video-capable multimodal model and honoring per-request media_io_kwargs are exposed; text-only instances are not affected, and versions before 0.18.0 lack runtime media_io_kwargs support. The CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N/VA:H) rates this a high-availability-impact, confidentiality- and integrity-neutral flaw, and no public exploit code has been identified at time of analysis, though the trigger is a simple documented parameter override.
Unauthenticated remote attackers can crash vLLM 0.20.0 through 0.29.x by submitting inconsistent multimodal metadata to the disaggregated /inference/v1/generate endpoint, which yields a negative text span in Qwen2.5-VL position construction and terminates the engine, denying service to subsequent requests. Exploitation is availability-only and rated high complexity: the attacker must first obtain and replay a valid multimodal item, then tamper with the serialized mm_placeholders, kwargs_data or mm_hashes fields, and the target must expose the scale-out multimodal generate endpoint. No public exploit code was identified at time of analysis; the validation fix ships in vLLM 0.30.0.
Memory exhaustion in vLLM's Nemotron-VL processor path allows unauthenticated remote callers to OOM-kill the inference worker and deny service to co-tenants. The Nemotron-VL processor modules set Pillow's Image.MAX_IMAGE_PIXELS to None at import time, permanently disabling the process-global decompression-bomb guard for every image decode in that process, so a pathological image submitted to /v1/chat/completions expands into unbounded memory. Exposure is limited to deployments that serve a Nemotron-VL model or otherwise import the affected processor modules, and the vendor fix ships in vLLM 0.25.0 via PR #47010; no public exploit code has been identified at time of analysis, and scoring is availability-only (CVSS 4.0 base 8.7, PR:N/UI:N).
Server-side request forgery in vLLM 0.9.2 through 0.23.x lets an API caller force a P2pNcclConnector prefill worker to open an outbound ZMQ connection to an attacker-chosen host by embedding a `___decode_addr_<host>:<port>` token in the `X-Request-Id` header, exposing the NCCL communicator unique_id and the KV-cache tensors of the targeted request and potentially stalling the worker on a blocking `ncclCommInitRank`. The flaw is conditional: it only applies to disaggregated-serving deployments started with `--kv-transfer-config` selecting the V1 `P2pNcclConnector` in the `kv_producer` role, and default vLLM installations are unaffected. The CVSS:4.0 vector indicates no privileges required (PR:N), with the caveat that a valid API key is needed when `--api-key` is configured. No public exploit was identified at time of analysis, and the vendor closed the issue in 0.24.0 by removing the affected connector.
Memory exhaustion in vLLM's multimodal chat audio path lets an authenticated API user submit a small compressed audio payload to /v1/chat/completions that decodes into very large PCM data, driving up server memory and degrading or halting availability. Deployments in the >= 0.19.0, < 0.24.0 range that accept audio content parts are affected; the fix in 0.24.0 extends the existing decoded-duration guard to AudioMediaIO, which currently calls load_audio(..., sr=None) with no max_duration_s bound. Exploitation requires a valid API key by default (PR:L) and an audio-capable deployment; no public exploit code was identified at time of analysis, and the issue is a sibling of the already-published speech-to-text decompression-bomb advisory.
A single crafted request to the Rust gRPC Generate or GenerateStream service in vLLM 0.22.0 through 0.23.x can abort EngineCore and leave the inference server unhealthy, producing a remote denial of service against availability only. Because the gRPC handlers forward attacker-supplied pre-tokenized prompt IDs to the engine without checking them against tokenizer or model vocabulary bounds, an out-of-vocabulary value such as 9000000 reaches the embedding lookup and terminates the process; no confidentiality or integrity impact is assessed. The vendor shipped a fix in 0.24.0, and no public exploit code has been identified at time of analysis - the main gating factor is whether the gRPC endpoint is network-reachable, since the advisory notes that deployments restricting it to already-authorized clients require that access and would score lower (PR:L, 6.5).
Remote denial of service in vLLM 0.22.0 up to but not including 0.24.0 allows remote attackers (CVSS PR:N) to crash EngineCore by sending a single Generate or GenerateStream request to the Rust gRPC frontend with output_logprobs enabled and more than 128 output_candidates.token_ids. The Rust converter copies those IDs into SamplingParams.logprob_token_ids without the Python-side 128-ID cap, vocabulary check, or logprobs-count consistency check, so the V1 GPU logprob sampler raises a fatal exception after execution begins. Only deployments exposing the Rust gRPC path on the vulnerable V1 sampler are affected; no public exploit identified at time of analysis, and the vuln.today priority is this_week.
An unauthenticated remote attacker who can reach the Rust gRPC Generate/GenerateStream frontend of vLLM 0.22.0 through 0.23.x can send a single small request that sets output_candidates.top_n or prompt_candidates.top_n above the server's configured max_logprobs cap - or to a value such as 2,147,483,648 that wraps negative when the protobuf uint32 is cast to i32 - and the unchecked count is forwarded into the V1 sampler's torch.topk call, terminating EngineCore and taking the inference service down for that request. The flaw is a missing validation and checked-conversion step in the Rust gRPC converter, which does not replicate the max_logprobs and negative-count guards that the Python SamplingParams validator already enforces; deployments that only expose the Python or OpenAI-compatible API are not reachable through this vector. Impact is availability only - no code execution, data access or model compromise is claimed - and no public exploit code or active exploitation has been identified at time of analysis; a fixed release (0.24.0) is available.
Remote unauthenticated memory exhaustion in vLLM 0.7.3 through versions before 0.31.0 allows clients to terminate shared multimodal inference servers by supplying oversized per-request mm_processor_kwargs, such as large image sizes, patch counts, crop counts, or frame counts, to processors including Isaac, InternVL, and H2OVL. Deployments are exposed when they serve a multimodal model and accept client-controlled mm_processor_kwargs without validation; text-only models and hardened configurations that disable or clamp these parameters are not affected. No public exploit was identified at time of analysis, and the impact is availability-only, with the highest practical risk for multi-tenant or internet-exposed inference APIs.
Cache aliasing in vLLM before 0.31.0 allows authenticated users of a shared deployment to receive another request's cached processed media or reuse first-block KV cache state by supplying colliding EXIF ImageID or cache_salt values. The flaw is only exploitable when image-processing and/or prefix-KV caches are shared across distinct callers or tenants and the attacker can control the relevant cache-key inputs; single-tenant or isolated-cache deployments have no cross-request target. No public exploit identified at time of analysis; the vendor CVSS 4.0 score is 7.1, and the independent assessment rates confidentiality impact high with limited integrity impact.
Remote code execution in vLLM 0.7.3 through 0.30.x lets remote, unauthenticated clients run arbitrary Python inside the API server process when a multimodal request to the /tokenize endpoint supplies a crafted mm_processor_kwargs.code_revision value, which vLLM forwards to Transformers AutoProcessor.from_pretrained and uses to select which revision of the model repository's dynamic processor code gets imported. Exploitation requires two non-default preconditions: the server must be running with trust_remote_code enabled, and the attacker must control (or be able to write) a revision in the model repository being served, so default hardened deployments with remote code disabled are not exposed. No public exploit code or confirmed active exploitation was identified at time of analysis, but the impact for exposed configurations is full confidentiality, integrity and availability loss (vendor CVSS 4.0 score 9.2; our independent CVSS 3.1 assessment of 8.1 reflects the high attack complexity created by the prerequisites).
Unauthenticated memory exhaustion in vLLM versions after 0.24.0 and before 0.31.0 can crash the API process when the MOSS-Audio model is served, because request-controlled mm_processor_kwargs values are cached in an unbounded dictionary. Attackers can send distinct or oversized mel_config values to the /tokenize endpoint, which bypasses --api-key authentication, steadily consuming host memory until the service dies. No public exploit identified at time of analysis; the vendor-released fix is vLLM 0.31.0, and only deployments actively serving MOSS-Audio with a reachable /tokenize endpoint are exposed.
Crafted /inference/v1/generate requests can permanently stall vLLM before 0.31.0 by killing the EngineCore input thread with an uncaught VLLMValidationError while /health continues to return 200. The trigger is a generate request that sets max_tokens to null-causing the min_tokens <= max_tokens validation to be skipped-together with an oversized min_tokens value, after which all subsequent generation requests hang until a manual restart. This is an availability-only flaw (CWE-248); the supplied CVSS 4.0 vector scores it 7.1 with PR:L, while our independent assessment uses CVSS 3.1 with PR:N, so authentication or network ACLs in front of the inference API materially reduce exposure, and no public exploit identified at time of analysis.
Denial of service in vLLM before 0.31.0 allows remote attackers to crash the entire serving instance by forging or reusing a client-supplied multimodal UUID so the P0/P1 processor caches disagree on token placeholders and hit a fatal mismatch. The flaw is reachable only when the deployment serves a multimodal model and exposes the multimodal inference API; text-only vLLM deployments are not affected. No public exploit was identified at time of analysis, and authentication requirements are conflicting in the supplied data: the CVSS 4.0 vector is PR:L while the independent assessment uses PR:N and the description says unauthenticated, so exposure depends on whether the endpoint is protected (vLLM's default server has no authentication per the assessment).
Heap corruption and process crash in vLLM audio transcription allow an authenticated remote attacker to repeatedly deny service to the inference API in versions before 0.29.0. Uploads to /v1/audio/transcriptions that fail primary decoding fall through to a PyAV/FFmpeg av.open() fallback guarded only by a file-size check, so a malformed IAMF container reaches FFmpeg's vulnerable IAMF parser and corrupts the heap, terminating the API process. The CVSS vector (PR:L) confirms authentication is required, impact is availability-only (no confidentiality or integrity effect), and no public exploit code or CISA KEV listing was identified at time of analysis; no EPSS score was supplied.
Denial of service in vLLM before 0.29.0 allows an authenticated API user to permanently disrupt the inference service with a single malformed request to the OpenAI-compatible POST /v1/completions or POST /v1/chat/completions endpoints. The server accepts user-supplied stop_token_ids and checks only that they are integers, not that they fall within the model's vocabulary/logits range; when min_tokens > 0 those ids are used as logits indices to suppress stop tokens, so an out-of-range value reaches a CUDA index_put_ operation and trips a device-side assertion that returns HTTP 500 and leaves EngineCore in a fatal state until the service is restarted. The impact is bounded to availability (no code execution or data disclosure) and exploitation requires valid API credentials plus exposure of the OpenAI-compatible endpoints; no public exploit code was identified at time of analysis, and the vendor has released a fix.
Pinned vLLM deployments (0.22.1 through 0.28.0) running the FunAudioChat or Tarsier2 architectures silently ignore the operator's --revision/--code-revision pin for several Hugging Face artifacts, allowing a subsequent change to the upstream repository's default branch to alter audio preprocessing, speech-tokenizer behavior, or Tarsier2 configuration without any change to the operator's configured pin. The result is a supply-chain integrity and reproducibility failure rather than a code-execution flaw: the advisory explicitly states it is residual to CVE-2026-47155 / GHSA-3ww4-5jv9-j5gm and does not constitute remote code execution or a trust_remote_code=False bypass, despite an 'RCE' tag appearing in some threat-feed metadata. There is no public exploit code identified at time of analysis and no confirmed active exploitation (CISA KEV); exploitation requires the narrow combination of an affected architecture, an operator using a revision pin, and an actor able to modify the upstream Hugging Face repository's default revision, so default general-purpose vLLM deployments are unaffected.
Out-of-vocabulary stop_token_ids in vLLM 0.22.0 through 0.23.0 cause a CUDA tensor indexing failure that drives EngineCore into a fatal state and forces a manual service restart. The trigger is a generation request that simultaneously sets min_tokens greater than zero and includes stop_token_ids outside the model's vocabulary bounds, slipping past missing validation in the Rust HTTP and gRPC frontends to reach MinTokensLogitsProcessor; CVSS 4.0 scores this 8.2, but the assessed impact is availability-only (C:N/I:N/A:H) and deployments enabling vLLM's optional API-key authentication would require a valid key, so real-world severity is lower than the headline score. No public exploit code or confirmed active exploitation is identified at time of analysis (not in CISA KEV), and a vendor patch is available per advisory GHSA-qff2-492f-9fm4, with ENISA EUVD-2026-87746 recording the affected range as 0.22.0 up to but not including 0.24.0.
Denial of service in vLLM deployments running versions before 0.29.0: an attacker with low-privilege access to the disaggregated serving endpoint /inference/v1/generate can submit an overlong token_ids list accompanied by a 'features' (multimodal) payload, bypassing prompt-length validation and causing a worker failure that takes down inference capacity. The issue is availability-only (no confidentiality or integrity impact) and is reachable over the network without user interaction, but exploitation requires that the deployment run in non-default disaggregated serving mode with a multimodal model whose processor reports skip_prompt_length_check=True (Nemotron Parse, Whisper, or FireRedLID), so standard single-node text-only vLLM installations are not exposed. Vendor-released patch: 0.29.0; no public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV.
Pre-inference resource exhaustion in vLLM up to and including 0.29.0 lets remote attackers force the API server or batch runner to fully download, base64-decode and materialize attacker-controlled media before the documented VLLM_MAX_AUDIO_CLIP_FILESIZE_MB compressed-audio cap (25 MB default) and the per-modality --limit-mm-per-prompt item limits are enforced. Four ingress paths are affected - the shared media-acquisition layer (HTTPConnection.get_bytes()/async_get_bytes()), the chat completions audio_url/base64 path, the batch speech runner, and the Rust frontend POST /tokenize route - with the /tokenize path unauthenticated by design and the chat/batch surfaces gated only when an API key is actually configured, so an attacker can allocate memory and consume outbound bandwidth proportional to an attacker-chosen body size or media-item count. Impact is availability-only (no code execution or data disclosure); the vendor CVSS 4.0 vector scores 7.1 with PR:L, while the independent assessment scores it 7.5 under CVSS 3.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) to reflect the unauthenticated /tokenize path, and no public exploit code was identified at time of analysis.
Denial of service in vLLM before 0.28.0 allows an unauthenticated remote attacker to poison the process's GPU context by sending a single request containing a negative token ID to the /v1/embeddings or /pooling endpoints, after which all subsequent inference requests fail until the server is restarted. The vulnerable endpoints are part of vLLM's OpenAI-compatible HTTP server and ship enabled in default configurations, and because vLLM provides no built-in authentication, the practical risk is governed entirely by whether the API is reachable by untrusted clients over a public or shared network. Impact is availability-only (assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H; vendor CVSS 8.7), no public exploit code was identified at time of analysis, and no KEV-listed active exploitation is reported.
Uncontrolled memory allocation in vLLM's transcription endpoint before 0.28.0 allows authenticated API clients to crash the entire server process by submitting FLAC audio files with forged, inflated sample rate headers. Because vLLM commonly operates as a shared API server across multiple tenants, a single authenticated attacker can deny service to all concurrent users. VulnCheck reported this with a CVSS 4.0 score of 7.1; no public exploit code or CISA KEV listing has been identified at time of analysis.
Remote code execution in vLLM's LlavaOnevision2 processor loader allows an attacker who controls a model repository to execute arbitrary code on systems that load that model, bypassing the trust_remote_code=False safety parameter entirely. All vLLM installations prior to version 0.28.0 are affected when loading LlavaOnevision2-architecture models; the security control that operators rely on to safely evaluate third-party models is silently non-functional for this processor class. No public exploit code has been identified and the vulnerability is not listed in CISA KEV, but the attack requires only the ability to publish a model to an accessible registry and social-engineer a user into loading it.
Denial of service in vLLM 0.12.0 through 0.23.x lets any authorized API caller crash the entire inference server by submitting a pure prompt-embeddings payload to the /v1/completions endpoint when a model using M-RoPE (multimodal rotary position embedding) is loaded. The malformed request trips a reachable assertion in the EngineCore process, which terminates the whole server rather than rejecting the single request. There is no public exploit identified at time of analysis and it is not listed in CISA KEV; the flaw is fixed in vLLM 0.24.0.
Denial of service in vLLM inference servers prior to 0.24.0 allows remote unauthenticated attackers to hang an inference worker indefinitely by submitting a single request with an adversarial regular expression via the structured_outputs.regex API parameter. The pattern is passed to grammar compiler backends (xgrammar with no guard, outlines with structural-but-not-complexity validation) where nested quantifiers trigger exponential state-space expansion (ReDoS). No public exploit identified at time of analysis, though the trivial request-based trigger makes weaponization straightforward.
Denial of service in the vLLM LLM inference server (all versions prior to 0.24.0) allows a remote client to crash the shared engine worker by sending a specific multi-request speculative decoding workload. The rejection sampler produces a recovered token equal to the vocabulary-size boundary, which is coerced to -1, written back into the drafter's input ids, and later dereferenced by the embedding/attention path, triggering a GPU device-side assertion that kills the worker. There is no public exploit identified at time of analysis and this CVE is not in CISA KEV; per CVSS the impact is availability-only (C:N/I:N/A:H) with a low EPSS profile expected for a crash-only bug.
Remote code execution in vLLM versions prior to 0.22.1 allows attackers to backdoor production LLM inference deployments through a dependency confusion attack in the project's Dockerfile. Because flashinfer-jit-cache was pulled via --extra-index-url with UV_INDEX_STRATEGY=unsafe-best-match while the name remained unregistered on PyPI, any attacker who claimed the name on PyPI with a higher version would have their code executed as root during every Docker build. No public exploit identified at time of analysis, but the supply-chain primitive is well understood and trivially weaponizable.
Denial of service in vLLM 0.8.0 and later allows remote unauthenticated attackers to crash the inference server by sending a single OpenAI-compatible chat completion request containing a video/jpeg data URL with thousands of comma-separated base64-encoded JPEG frames. The VideoMediaIO.load_base64() method decodes every frame without enforcing a count limit, exhausting server memory. No public exploit identified at time of analysis, but an upstream fix commit is available on GitHub.
Remote code execution in vLLM 0.14.1 occurs because `trust_remote_code=True` is hardcoded inside the NemotronVL and KimiK25 model loaders, silently overriding the operator's explicit `--trust-remote-code=False` safety flag. Any deployment that loads a malicious or compromised HuggingFace repository for these model architectures will execute attacker-controlled Python in the inference process, despite UI:R requiring an operator to initiate the model load. No public exploit is identified at time of analysis, but the issue is an incomplete fix for CVE-2025-66448 and CVE-2026-22807, indicating the regression pattern is already well understood.
vLLM versions 0.5.5 through 0.17.x use incorrect mono audio downmixing via numpy.mean instead of the ITU-R BS.775-4 weighted standard, causing audio processed by AI models to diverge from human perception. An authenticated remote attacker with low privileges can exploit this inconsistency to manipulate audio-based model outputs or infer mismatches between expected and actual audio processing, affecting integrity of audio-driven inference pipelines. The vulnerability has been patched in vLLM 0.18.0.
CPU and memory exhaustion in vLLM's /v1/responses endpoint affects versions 0.16.0 up to (but not including) 0.32.0, where an authenticated caller can inject a request-level Jinja chat template that bypasses the `trust_request_chat_template` policy gate. Only availability is impacted (no confidentiality or integrity loss), and exposure is limited to servers started with the documented default `trust_request_chat_template=False` and no explicit `--chat-template`, since that is the configuration in which the request-supplied `chat_template` key survives into the renderer. No public exploit code and no CISA KEV entry were identified at time of analysis, and the vendor's advisory rates the issue as Moderate.
vLLM's OpenAI-compatible server before 0.32.0 registers Starlette CORSMiddleware with allowed_origins defaulting to ["*"], so a malicious web page loaded by a victim can issue cross-origin requests to a vLLM server the browser can reach and read the responses. When no --api-key or VLLM_API_KEY is configured - the default - endpoints such as GET /v1/models and POST /v1/chat/completions are reachable, letting the page enumerate models, drive chat completions, burn GPU time, and read model output through the victim's browser; if a key is set, the guarded prefixes require that the caller already hold a usable token. Cookie-based CSRF does not apply because allow_credentials is False by default, and exploitation needs user interaction plus a browser-reachable server, which is why this scores only 3.4 and is tracked as monitor priority; no public exploit code was identified at time of analysis.
Out-of-vocabulary token IDs slip past vLLM's prompt validation and can crash the inference engine, turning a single malformed request into a denial of service. Releases prior to 0.32.0 derive max_token_id from the tokenizer's vocabulary count rather than the largest valid index, so a pre-tokenized prompt carrying the ID equal to the vocabulary size is accepted and reaches the embedding lookup one row out of range, raising a CUDA device-side assert that poisons the context and terminates the engine. The crash is confined to models whose vocabulary is an exact multiple of the 64-row embedding padding size (Llama-2-family, vocab 32000) served at tensor-parallel size 1; the assessed CVSS 3.1 score is 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), reflecting that low-privilege API access is needed and that availability is the only impacted property, and no public exploit was identified at time of analysis.
Denial of service in vLLM: any deployment serving the DeepSeek-OCR model family (deepseek-ai/DeepSeek-OCR, DeepSeek-OCR-2, or baidu/Unlimited-OCR) can be permanently killed by a single schema-valid chat request containing an ordinary half-black/half-white 1024x1024 PNG, whose pixel values cancel to exactly zero after normalization. That zero sum makes the image parser return no embedding, which trips a fatal encoder-output assertion inside the EngineCore worker; the API server raises EngineDeadError and exits, taking down every in-flight and future request until a manual restart. Affected versions run from 0.11.1 through before 0.32.0 on default configuration, the vendor advisory documents a verified end-to-end reproduction, but there is no CISA KEV listing and no public exploit code identified at time of analysis; the priority rating places remediation in the this-month window rather than emergency response.
Denial of service in vLLM prior to 0.32.0 lets a remote client terminate the entire inference engine by submitting a single legal audio clip - a roughly 10-minute silent recording is enough, no crafted content required. When the server hosts microsoft/Phi-4-multimodal-instruct (or another model reusing its audio tower), the Phi-4 conformer encoder runs attention in eager mode by default, materializes a full attention probability matrix per layer for every 500-frame chunk, and retains it on the module, so GPU memory climbs monotonically within one request until a CUDA out-of-memory error kills EngineCore for all users; the advisory reports worker death in about six seconds and the API then returns EngineDeadError. No public exploit code was identified at time of analysis and the issue is not in CISA KEV; the authoritative assessment rates this a genuine but moderate-priority availability issue, rated high on availability only (C:N/I:N/A:H) and unauthenticated where the API is exposed, while deployments not serving this audio-capable model are unaffected.
Denial of service in vLLM 0.19.0 through 0.31.x lets a caller who holds a valid API credential hand the server a hostile Jinja2 chat template - either directly in the request when the operator has not set --chat-template, or indirectly through a model repository whose tokenizer_config.json carries one - and hang every chat-style endpoint on that API-server replica until the process is restarted. The render runs inside a sandboxed Jinja environment with no wall-clock timeout, no output-size cap and no loop or binop bound, on a render pool that defaults to a single non-interruptible worker, so a tiny non-terminating template wedges /v1/chat/completions, /v1/responses, /tokenize and the chat pooling/invocations paths for all tenants, while a string-multiplication variant instead OOM-kills the process. Impact is availability-only across tenants of one replica (CVSS:3.1 6.5, PR:L), Harmony/gpt_oss models skip the affected Jinja path, and no public exploit code was identified at time of analysis; the vendor shipped a fix in 0.32.0.
Concurrent constrained-decoding traffic against vLLM servers running versions before 0.31.0 can leave a stale token allowlist in a recycled batch slot, so a victim's unrestricted generation request is silently constrained to the attacker's token set. The flaw is in InputBatch.condense(), which recycles finished request slots without clearing allowed_token_ids; remote unauthenticated attackers who can reach the generation API, including the unauthenticated /invocations endpoint, can trigger it by submitting many concurrent constrained requests while a race with slot reuse is won. Impact is integrity-only - the victim's output is degraded or steered, but no victim data is read - and success is timing- and load-dependent (CVSS AC:H with attack requirement AT:P). No public exploit code or confirmed active exploitation has been identified at time of analysis, and the issue is fixed in vLLM 0.31.0.
Denial of service in vLLM up to and including 0.31.0 lets a remote, authenticated user who can submit inference requests crash the serving engine by combining a prompt_embeds input with token penalty parameters (frequency, presence, or repetition), a combination that drives get_token_bin_counts_and_mask in vllm/model_executor/layers/utils.py into a fault. Publicly available exploit code exists in the form of a published reproduction script, and the vendor had not responded to the early issue report at the time of analysis, so unpatched, internet-exposed or multi-tenant deployments that accept such requests are exposed to availability loss. Impact is limited to availability of the serving process - no data disclosure or integrity compromise has been demonstrated.
An out-of-bounds read in vLLM up to and including version 0.31.0 lets a caller with low-privilege access to the completions API drive the SSM convolution path past the end of a buffer, degrading availability of the inference worker. The flaw is confined to deployments that serve Mamba/Mamba2-architecture models, because it lives in conv_ssm_forward of vllm/model_executor/layers/mamba/mamba_mixer2.py; instances running only standard transformer models are unlikely to reach the vulnerable code. Publicly available exploit code exists, but there is no confirmed active exploitation (not listed in CISA KEV); the independent assessment bounds impact to low availability loss with no confidentiality or integrity effect, making this a moderate rather than top-tier priority.
Malformed cache_salt values submitted to vLLM's OpenAI-compatible inference endpoints can crash the EngineCore process and deny service to every concurrent user on deployments configured with the LMCache-MP connector. Only vLLM releases prior to 0.30.0 are affected, and exploitation requires low-privilege API access (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, base score 6.5) plus the non-default LMCache-MP connector; a cache_salt containing '@', '/', '\\', or NUL, or longer than 128 characters, raises an uncaught ValueError during scheduler cache lookup. The flaw is fixed in version 0.30.0, and no public exploit code or confirmed active exploitation was identified at time of analysis, making this a genuine but moderate-priority availability issue rather than a high-severity emergency.
vLLM versions prior to 0.30.0 derive the flash late-interaction query-cache key from the caller-controlled X-Request-Id header, so an authenticated API caller on a shared deployment can collide with a victim's in-flight request and cause the victim's documents to be scored against the attacker's query through the /score and /rerank endpoints, while shared use counters can also give rise to a late-interaction cache-miss error. The assessed vector is CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:L (base 4.2), reflecting a narrow concurrency race that requires knowledge of or a lucky guess at the victim's request identifier, and no confidentiality impact; there is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV). The issue is fixed in vLLM 0.30.0, and the practical risk is confined to multi-tenant or otherwise shared deployments that actually enable the flash late-interaction scoring path.
Improper input validation in vLLM's disaggregated scale-out (token-in-token-out) serving path lets an authenticated low-privilege remote caller send forged multimodal request fields to the /inference/v1/generate endpoint and terminate the shared EngineCore process. Affected are vLLM releases prior to 0.30.0 that are explicitly deployed in the disaggregated scale-out mode; attacks on the cache variant additionally require the attacker to know or induce a victim's content hash so that forged cache identifiers (mm_hashes) match, enabling cross-request encoder-cache poisoning or retrieval and, in the same input-validation failure, corrupted replayed transport semantics from dropped sparse placeholder masks. Both confidentiality and integrity impact are therefore low-severity and preconditional, while availability impact on the shared engine is high; the CVSS 3.1 vector is AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Multimodal inference requests to vLLM deployments running versions prior to 0.28.0 can trigger a process-level assertion failure that takes down the shared serving engine, denying service to all concurrent users. The flaw is a state desynchronization in the default mirrored multimodal LRU cache: a media hash can be committed in the frontend MultiModalProcessorSenderCache during rendering before engine admission, but if the request is rejected, the engine-side MultiModalReceiverCache never stores the corresponding payload, so any later request reusing that hash reaches an assertion reading "Expected a cached item." Exploitation requires only the ability to submit requests to the service (PR:L, network-reachable, no user interaction), is confined to deployments serving multimodal models, and results in availability impact only; no public exploit code was identified at time of analysis and upgrading to 0.28.0 removes the issue.
vLLM deployments prior to 0.30.0 with prefix caching enabled (the default) fail to carry the caller's cache_salt value across Harmony tool continuations submitted to "POST /v1/responses", so continuation prefixes land in the global unsalted prefix-cache namespace. This lets an authenticated tenant who can reconstruct a victim's low-entropy post-tool conversation history submit the same continuation and read the cached_tokens_per_turn counter as a hit/miss oracle, confirming whether that prefix was previously processed and thereby defeating salt-based tenant isolation of the cache. This is a genuine but low-severity, low-priority issue: the assessed vector is CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N, exploitation requires authenticated access, prefix caching to be on, cache_salt salting to be in use, and the victim's history to be low-entropy and reconstructable, and only the isolation property leaks - no direct model output or prompt content is disclosed. No public exploit code and no confirmed active exploitation were identified at time of analysis.
Denial of service in vLLM through 0.26.0 lets remote attackers crash or exhaust inference workers by submitting inputs containing deeply nested '{...}' or '[...]' delimiter structures that the Gemma4UnifiedParser expands recursively without any depth bound, exhausting the thread stack. The flaw is confined to the Rust parser component (rust/src/parser/src/unified/gemma4.rs) and only affects deployments that route requests or model output through the Gemma4 unified parser - typically Gemma-family model serving with tool-calling or structured-output parsing. Publicly available exploit code exists (a published GitHub gist demonstrates the nested-input trigger), and the vendor has released a fix in v0.29.1rc0 via PR #54303; no CISA KEV listing or confirmed in-the-wild exploitation was provided in the source data. Impact is availability-only (no data disclosure, no code execution), and the CVSS 4.0 vector scores it 6.9 with E:P while the independent assessment rates it CVSS 3.1 A:H.
Unauthenticated remote attackers can exhaust GPU memory on vLLM deployments before 0.29.0 that accept video inputs, by requesting different sampler subclasses whose decoder-allocation counters increment independently and thus sidestep the shared PyNvVideoCodec decoder limit. The result is availability degradation (GPU memory exhaustion) rather than data disclosure or code execution, and success is not deterministic - it depends on repeated requests that win allocation and timing conditions (AC:H, AT:P), with additional practical constraints where the API is gated by an API key or network gateway. No public exploit code has been identified and the issue is not confirmed as actively exploited (CISA KEV); a vendor patch is available per the upstream GitHub security advisory.
Remote denial of service in vLLM versions before 0.29.0 allows unauthenticated clients to bypass the configured multimodal audio clip size limit (VLLM_MAX_AUDIO_CLIP_FILESIZE_MB) by submitting oversized audio through chat endpoints, causing excessive memory and CPU consumption during decoding. The CVSS vector confirms this is remotely reachable with no privileges (PR:N) and no user interaction, but impact is availability-only (VA:L) - there is no data exposure, integrity loss, or code execution. No public exploit code has been identified at time of analysis, and a vendor-released patch (0.29.0) is available, making this a genuine but low-severity resource-exhaustion issue rather than a high-impact breakout. Exploitability in practice depends on whether the audio-capable chat endpoint is exposed without an authenticating reverse proxy, request-size limits, or rate limiting, and on the host's memory/CPU headroom.
Denial of service in vLLM releases before 0.29.0 allows unauthenticated remote attackers to stall the single EngineCore scheduler thread by sending HTTP requests with multi-hundred-megabyte cache_salt values to the OpenAI-compatible or Anthropic-compatible API endpoints. The oversized salt value is pickle-serialized and SHA-256 hashed on the scheduler thread, so a single request blocks scheduling and inference for all concurrent requests, degrading or halting service. No public exploit code was identified at time of analysis and the issue is not in CISA KEV, so real-world risk is concentrated on internet-facing or multi-tenant vLLM deployments that expose these endpoints without an authenticating gateway or upstream request-size limits.
Out-of-bounds bad_words token indices in vLLM through 0.29.0 are not validated against the model's generation output width, allowing the indices to be written past the logits buffer and corrupt the sampling state of concurrently batched requests, so unrelated in-flight HTTP requests can receive incorrect output tokens. Exploitation requires API access sufficient to submit sampling requests with a bad_words parameter (authenticated, PR:L), a target model whose tokenizer exposes input-only placeholder tokens with IDs above the model's logits vocabulary (typically multimodal models such as those with <|audio|> tokens), and concurrent requests sharing the batch, so a text-only model whose tokenizer vocabulary equals its output vocabulary is not affected. No public exploit code has been identified at time of analysis and there is no KEV listing; the issue is a low-severity integrity/quality-of-output defect rather than a confidentiality or availability compromise, and an upstream fix is available as a pull request.
Out-of-bounds writes in the Triton bincount sampling kernel of vLLM through 0.29.0 let unauthenticated remote clients corrupt a neighboring request's repetition-penalty state by submitting multimodal audio input that contains a token ID equal to the model's vocabulary size. The root cause is an unvalidated array index (CWE-129): prompt and output token IDs are used to index the penalty prompt-presence bitset and output bin counts without any bounds check against vocab_size, so a one-past-the-end token spills into the adjacent request's mask/count rows. Impact is integrity-only and confined to altered repetition-penalty behavior for concurrently served requests - there is no code execution, data disclosure, or denial of service - and exploitation requires a CUDA GPU with compute capability >= 8.0, a multimodal model accepting audio tokens, and concurrent traffic in a shared, multi-tenant deployment; no public exploit code and no confirmed active exploitation have been identified at time of analysis.
Sampling-parameter validation in vLLM before 0.29.0 checks the allowed_token_ids allowlist against the tokenizer vocabulary size instead of the model's output logits width, so a remote client calling the OpenAI-compatible inference API can supply token IDs that are valid for the tokenizer but out of range for the model output (the advisory's cited case is a multimodal model with 128257 tokenizer tokens versus 128256 output logits). Those out-of-range IDs pass validation and reach the GPU sampling path, where LogitBiasState's Triton logit-bias kernel indexes past the valid logits row and corrupts shared GPU logits state, causing concurrent victim requests in the same batch to sample tokens outside their own allowlists. The impact is limited to sampling-constraint integrity (no data disclosure, crash, or code execution) in shared or multi-tenant deployments, and it is inert on models whose tokenizer and output vocabularies are the same size; there is no public exploit identified at time of analysis and no confirmed active exploitation (not listed in CISA KEV).
GPU memory exhaustion in vLLM versions prior to 0.28.0 lets an attacker with low-privileged API access (PR:L in the CVSS vector) force the server to load the PyNvVideoCodec hardware video decoder on demand by setting media_io_kwargs.video.video_backend to 'pynvvideocodec' in a Chat Completions or Responses request, even when the operator configured a software decoder at startup. Because the engine budgets decoder VRAM only from static configuration, the request-selected backend allocates a CUDA context, decoder surfaces, and decoded-frame buffers that were never deducted from the KV-cache budget, so repeated video requests can exhaust shared GPU memory and cause request failures, worker crashes, and denial of service. The issue is availability-only (C:N/I:N/A:H) and exploitable only on video-capable GPU deployments running a video-accepting model with PyNvVideoCodec actually installed; vLLM 0.28.0 and later are not affected. No public exploit code was identified at time of analysis and the flaw is not confirmed actively exploited (CISA KEV), though the upstream fix commits and PR are publicly visible.
Out-of-memory worker crashes in vLLM can be induced by a single small compressed audio payload submitted to the /v1/chat/completions input_audio path, because that code path decodes audio without the VLLM_MAX_AUDIO_DECODE_DURATION_S guard already enforced on /v1/audio/transcriptions - an unbounded resource allocation flaw (CWE-770) that expands a tiny compressed file into a very large float32 PCM buffer. The issue affects every vLLM release prior to 0.24.0 that serves an audio-capable model and exposes the chat completions endpoint, with inline data URLs additionally escaping VLLM_AUDIO_FETCH_TIMEOUT; impact is availability-only (no confidentiality or integrity loss). Per the assessed vector the attack is remote and unauthenticated (PR:N, UI:N), while the vendor-published vector scores it PR:L, so whether any front-of-service authentication gate exists is deployment-specific; at time of analysis no public exploit code and no confirmed active exploitation were identified, and a vendor patch exists in 0.24.0.
Inefficient algorithmic complexity (CWE-407) in vLLM up to and including 0.29.0 causes the thinking-budget marker search in vllm/v1/sample/thinking_budget_state.py to re-scan an ever-growing output token buffer on every decode step, degrading throughput and consuming CPU when serving reasoning-capable models. An authenticated API client (CVSS 4.0 vector lists PR:L) that sets the thinking_token_budget sampling parameter can trigger the quadratic blowup, but only when the generated output never contains the configured reasoning start/end marker token sequences, so the internal search cursors fail to advance; the practical worst case is partial availability loss (slowed or stalled generation per affected request) rather than a crash, code execution, or any confidentiality/integrity impact. This is a low-severity availability issue - no public exploit code has been identified at time of analysis and there is no CISA KEV listing - and the vendor score of 5.3 is well calibrated to the assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L. Upstream fix is available as GitHub PR vllm-project/vllm#51133, which awaits acceptance, so no released patched version is independently confirmed.
Unbounded buffering of unacknowledged KV-transfer acknowledgements in the MoRIIO connector of vLLM 0.26.0 and 0.27.0 allows a remote, unauthenticated client to grow worker memory indefinitely and degrade or crash LLM inference serving. The root cause is CWE-400 uncontrolled resource consumption in moriio_connector.py, where acknowledgements whose transfer mapping is not yet populated are appended to _pending_unmapped_acks with no TTL or size cap across request_finished, get_finished and _handle_release_message. Impact is availability-only (CVSS 4.0 base 6.9, AV:N/AC:L/PR:N/UI:N/VA:L); no public exploit code and no CISA KEV
A resource-exhaustion (denial of service) flaw in vLLM's OpenAI-compatible /v1/chat/completions endpoint lets a caller- or model-supplied Jinja chat_template drive nested range() loops whose evaluation cost grows as O(N^depth), tying up a request-runtime worker thread for tens of seconds. vLLM releases up to and including 0.27.1 are affected (EUVD lists 0.27.0 and 0.27.1), with the CPE range expressed as vllm-project:vllm:* so earlier releases are plausibly in scope too. Publicly available exploit code exists, and CVSS 4.0 rates the issue only 2.1 with availability impact rated Low; a fix PR that introduces a minijinja evaluation 'fuel' budget is still awaiting acceptance.
Denial-of-service in vLLM's Rust-based tiktoken tokenizer allows a local low-privileged attacker to crash the vLLM process by supplying a crafted vocab file containing duplicate token ranks. The TiktokenTokenizer::new() function in the Rust tokenizer backend previously panicked unconditionally when parsing a tiktoken file with two tokens sharing the same rank value, rather than returning a graceful error. A public proof-of-concept exploit is available via GitHub Gist; no patch has been merged as the fixing pull request remains open.
Unbounded audio extraction in vLLM 0.10.2-0.27.x enables remote denial of service against NanoNemotronVL model deployments. The root cause is an asymmetric protection gap: `_extract_audio_from_videos` in `nano_nemotron_vl.py` calls `load_audio_pyav` without the size or duration guard parameters enforced on the direct audio upload path, bypassing the `VLLM_MAX_AUDIO_DECODE_DURATION_S` and `VLLM_MAX_AUDIO_DECODE_BYTES` environment variable limits entirely. An attacker submitting a maliciously compressed video via the multimodal inference API forces the server to allocate gigabytes of memory during audio decoding, crashing the service. No public exploit code or CISA KEV listing has been identified at time of analysis; vendor-released patch is available in vLLM 0.28.0.
Remote denial-of-service in vLLM before 0.27.0 allows unauthenticated network attackers to activate the DeepStream GPU video-decode backend per-request, initialize the process-wide GPU decode pool, and submit video content that bypasses pixel-limit enforcement, causing partial availability loss for concurrent inference requests. The root cause is vLLM's failure to classify DeepStream as a GPU backend subject to resource controls combined with an omitted pixel-limit check in the DeepStream decode path (CWE-400). No public exploit code has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog.
Server-side request forgery in vLLM's MiMoV2OmniMultiModalProcessor allows authenticated API users to bypass the framework's media access controls, enabling arbitrary file reads on the vLLM host and SSRF requests to internal network resources. The flaw affects all vLLM releases prior to 0.26.0 where attacker-controlled image and audio URL strings were passed directly to _fetch_image, requests.get, and Image.open instead of routing through the MediaConnector abstraction that enforces allowed_media_domains and allowed_local_media_path restrictions. No public exploit code or CISA KEV listing exists at time of analysis, but the low attack complexity and network-accessible vector make this a meaningful risk for deployments serving untrusted authenticated users via the affected multimodal processor.
Uncontrolled resource consumption in vLLM's OpenAI-compatible completions endpoint allows any authenticated API client to exhaust CPU, memory, async scheduling capacity, and engine request slots with a single crafted request. Affected versions span 0.19.0 through 0.25.x; the issue is fixed in 0.26.0. No public exploit code has been identified and CISA has not listed this in KEV, but the attack is trivially constructable by any client with a valid API credential.
Cross-user inference data leakage in vLLM prior to 0.27.0 exposes one batched user's prompt or completion output to another user sharing the same GPU inference batch. The root cause is a 32-bit integer overflow in the CUDA kernel `act_and_mul_kernel` within `activation_kernels.cu`, where the pointer arithmetic `blockIdx.x * 2 * d` wraps around when token indices and hidden-dimension sizes are large enough, redirecting the kernel to read from an adjacent user's input buffer. No active exploitation has been confirmed (no CISA KEV listing), but the vendor has patched the issue in v0.27.0 and a detailed GitHub advisory and PR diff are publicly available.
Race condition in vLLM's prompt embedding loader allows concurrent API requests to bypass the sparse tensor invariant guard introduced for CVE-2025-62164, permitting an invalid sparse tensor to reach `tensor.to_dense()` and cause availability disruption. Affected deployments span versions 0.20.2rc0 through 0.25.x and are limited to instances with `enable_prompt_embeds` explicitly enabled. No public exploit code or CISA KEV listing exists at time of analysis; the fix is confirmed in v0.26.0.
Uncontrolled resource consumption in vLLM's lm-format-enforcer structured output backend (all versions prior to 0.26.0) enables unauthenticated remote denial of service via the /v1/completions API endpoint. By submitting a crafted catastrophically backtracking regular expression to the structured_outputs.regex parameter, a remote attacker can saturate an entire CPU core and stall the structured-output engine path indefinitely - blocking inference requests that rely on the lm-format-enforcer backend for all concurrent users. No public exploit code has been identified and the vulnerability is not listed in CISA KEV, though the attack primitive (ReDoS against an exposed API) is well-understood and trivially constructible by any attacker familiar with catastrophic regex patterns.
Information disclosure in vLLM prior to version 0.26.0 leaks server filesystem internals - including OS usernames, home and virtual-environment directory paths, Python version, internal package structure, line numbers, and endpoint handler names - through HTTP error responses. Any unauthenticated network attacker can trigger this by sending malformed JSON to the OpenAI-compatible API endpoints, requiring zero privileges and no special configuration beyond a default vLLM deployment. No public exploit code has been identified at time of analysis, and no CISA KEV listing exists; however, the trivial exploitation bar (a single malformed HTTP request) and the reconnaissance value of the leaked data elevate real-world risk above the CVSS 5.3 score alone implies.
Memory exhaustion in vLLM 0.22.0-0.23.0 allows authenticated API callers to crash or destabilize the inference server by uploading arbitrarily large audio files. The `/v1/audio/transcriptions` and `/v1/audio/translations` endpoints invoke `request.file.read()` to fully buffer multipart uploads into process memory before the `VLLM_MAX_AUDIO_CLIP_FILESIZE_MB` size guard is evaluated, meaning the size limit is checked only after the damage is done. No public exploit is identified at time of analysis; vendor-confirmed fix is available in version 0.24.0.
Denial of service in vllm 0.19.0's OpenAI-compatible serving path allows remote unauthenticated attackers to exhaust scheduler resources by submitting requests with unbounded logprob counts. The root cause, confirmed by PR diff analysis, is the absence of any per-batch logprob budget in the v1 scheduler: requests specifying logprobs=-1 (full vocabulary) multiplied across parallel sequences (n) generate massive compute and memory overhead with no cap, blocking or crashing the inference server. Publicly available exploit code exists (GitHub issue #37343); no confirmed active exploitation at time of analysis.
vllm-project vllm version 0.6.0 contains a vulnerability in the AsyncEngineRPCServer() RPC server entrypoints. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.