Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Primary rating from Vendor (VulDB).
CVSS VectorVendor: VulDB
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
3Blast Radius
ecosystem impact- 1 pypi packages depend on vllm (1 direct, 0 indirect)
Ecosystem-wide dependent count for version 0.19.0.
DescriptionCVE.org
A vulnerability was identified in vllm-project vllm 0.19.0. This issue affects some unknown processing of the component OpenAI-compatible Serving Path. Such manipulation leads to denial of service. It is possible to launch the attack remotely. The exploit is publicly available and might be used. The pull request to fix this issue awaits acceptance.
AnalysisAI
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.
Technical ContextAI
vllm is a high-throughput LLM inference engine (cpe:2.3:a:vllm-project:vllm:*) that exposes an OpenAI-compatible HTTP API for text generation. The vulnerable component is the v1 scheduler (vllm/v1/core/sched/scheduler.py), which iterates over queued requests and batches them for GPU execution. When a client request includes the OpenAI logprobs parameter, the scheduler must compute and return log-probabilities over the model's vocabulary for each generated token. CWE-404 (Improper Resource Shutdown or Release) applies here in the sense that the scheduler does not enforce any upper bound on the aggregate logprob computation cost across a batch - a resource-limiting control that should exist is entirely absent. The PR diff shows the scheduler had no _get_request_logprobs_cost() function and no max_num_batched_logprobs budget variable before the fix. The logprobs=-1 edge case is especially severe: the scheduler would dynamically fetch the full vocabulary size (potentially 100K+ tokens) and multiply it by the number of parallel sequences (n), creating astronomical compute cost from a single API request.
RemediationAI
Upstream fix available (PR/commit); released patched version not independently confirmed - PR #37594 at https://github.com/vllm-project/vllm/pull/37594 implements the fix but was awaiting acceptance at time of analysis. Monitor that PR for merge and apply the patched release once tagged. As an immediate compensating control, restrict access to the OpenAI-compatible API endpoint at the network layer so that only trusted, authenticated clients can submit inference requests - this directly addresses PR:N exploitation. If the vllm deployment must remain accessible, configure an API gateway or reverse proxy to validate and cap the logprobs parameter in incoming requests, rejecting or clamping values above a safe threshold (e.g., reject logprobs=-1 or logprobs > 20); note this requires application-level request inspection and may break legitimate high-logprob use cases. Operators can also launch vllm with reduced parallelism (lower n limits) to reduce the per-request damage ceiling, at the cost of throughput. The fix itself introduces --max-batched-logprobs as a CLI argument, defaulting to 1000 per batch - once the PR is merged, setting this explicitly to a low value adds defense in depth against future variants.
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated critical severity (CVSS 10.0
vllm-project vllm version v0.6.2 contains a vulnerability in the MessageQueue.dequeue() API function. Rated critical sev
Information exposure in vLLM inference engine versions 0.8.3 to before 0.14.1. Invalid image requests to the multimodal
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated high severity (CVSS 7.5), th
vLLM before version 0.14.1 contains a server-side request forgery vulnerability in the MediaConnector class where incons
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated medium severity (CVSS 6.5),
Uncontrolled resource consumption in vLLM's OpenAI-compatible completions endpoint allows any authenticated API client t
Vllm versions up to 0.12.0 is affected by allocation of resources without limits or throttling (CVSS 6.5).
Remote code execution in vLLM 0.10.1 through 0.13.x lets an attacker who controls the model repository or path run arbit
Server-Side Request Forgery in vLLM's multimodal MediaConnector allows remote attackers to coerce the inference server i
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated critical severity (CVSS 9.0)
Remote code execution in vLLM versions prior to 0.22.1 allows attackers to backdoor production LLM inference deployments
Same weakness CWE-404 – Improper Resource Shutdown or Release
View allSame technique Denial Of Service
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-31810
GHSA-98f3-hwg4-4rf7