EUVD-2026-109433
GHSA-2hvf-qprp-xr9w
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach Rust gRPC Generate endpoint
-
DeliverySend request with oversized top_n
-
ExploitBypass max_logprobs validation
-
Executiontorch.topk fails in V1 sampler
-
ImpactEngineCore terminates, service denied
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V2 - Validation and Business Logic Input validation, allowlisting
|
| Exploitation Conditions | Requires a network-reachable vLLM Rust gRPC frontend (the Generate/GenerateStream API) running an affected version >=0.22.0 and <0.24.0, with a request setting output_logprobs=true and output_candidates.top_n (or prompt_logprobs=true and prompt_candidates.top_n) to a value exceeding the configured max_logprobs cap or large enough to wrap the uint32-to-i32 cast negative. The vulnerable path is specific to the Rust gRPC converter, which omits the max_logprobs and range checks that the Python SamplingParams validator enforces; deployments that only expose the Python/OpenAI API are not affected by this vector. Limiting factors: exploitation depends on the Rust gRPC endpoint being deployed and reachable, and if the operator restricts that endpoint to already-authorized clients (a deployment-layer credential), effective privilege required rises to PR:L; impact is confined to single-request denial of service with no data exposure or code execution. |
| Impact | This is a genuine but bounded availability risk. The input CVSS 4.0 vector (8.2, AV:N/AC:H/AT:P/PR:N/UI:N/VA:H) agrees with the GHSA that impact is availability-only (VC:N/VI:N/VA:H) and network-reachable without authentication (PR:N), but it disagrees on complexity: the input assigns AC:H/AT:P whereas the mechanism described in the GHSA - a single small gRPC request carrying an oversized or integer-wrapping top_n (e.g. 1000000 or 2147483648) - is a deterministic, attacker-controlled trigger with no race, timing, or external precondition, which the GHSA scores as AC:L with no attack requirement. That inflated complexity is the main reason to treat the raw 8.2 as conservative on mechanism but not on severity. No EPSS score and no CISA KEV entry are present in the input, and no exploit/PoC is marked available, so there is no public exploit identified at time of analysis; PR #44680 is a related patch PR that explicitly leaves this top_n/prompt_logprobs vector out of scope, not a working exploit. The vuln.today decision label is this_week (not act_now/emergency), consistent with a reliably triggerable single-request DoS that causes no confidentiality, integrity, code-execution, or data-access impact. Net: a real priority to patch promptly for anyone exposing the Rust gRPC frontend, but not a drop-everything emergency - it is a crash/DoS, not compromise. One further caveat: whether PR:N truly applies depends on deployment, since the GHSA notes the gRPC surface may in practice be reachable only to already-authorized clients (its conservative alternative is PR:L). |
| Exploit ScenarioDerived | An attacker who can reach a vLLM Rust gRPC Generate or GenerateStream endpoint sends a small request with output_logprobs=true and output_candidates.top_n set to an oversized value such as 1000000 (or 2147483648, which wraps to a negative i32), bypassing the default max_logprobs cap of 20 that the Python SamplingParams validator would enforce. The untrusted count reaches torch.topk in the V1 sampler after execution begins, raising an exception that EngineCore treats as fatal and terminating the engine, denying service to all clients. No public exploit is identified at time of analysis, though the trigger is fully specified in the GHSA advisory. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 25, 2026
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.
RemediationAI
Upgrade the vllm package to 0.24.0 or later, which is the vendor-released fix containing checked conversion of CandidateTokens.top_n and rejection of values above the configured max_logprobs before any engine request is submitted (per GHSA-rwfw-xvg3-3937). If upgrading immediately is not possible, the actionable compensating controls are deployment-level: do not expose the Rust gRPC Generate/GenerateStream endpoint to untrusted networks, and instead place it behind a network ACL or a deployment-layer credential so that only already-authorized clients can reach it - note that this raises the effective privilege required from PR:N to PR:L rather than eliminating the bug, and the wrapped-top_n DoS remains reachable for any client that is allowed in. If the Rust gRPC frontend is not needed, disable or do not deploy it and serve traffic through the Python/OpenAI-compatible API, which enforces the max_logprobs and negative-count checks; the trade-off is loss of the gRPC interface for existing clients. vLLM documents a --max-logprobs option, but lowering the cap does not mitigate this issue because the Rust converter never compares the supplied top_n against that cap. Verify remediation by confirming the deployed version is 0.24.0+ and, where possible, by testing that unary Generate and streaming GenerateStream requests with output_logprobs/prompt_logprobs and top_n of 21, 1,000,000 and 2,147,483,648 now return an invalid-argument error under the default configuration.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
vLLM's gRPC surface is defined by protobuf messages where ResponseOptions carries optional CandidateTokens selectors for output_candidates (field 7) and prompt_candidates (field 3), and CandidateTokens exposes a oneof select of uint32 top_n, token_ids, or all. In rust/src/server/src/grpc/convert.rs the Rust converter maps Select::TopN(n) to (*n as i32, None) and assigns the result directly to params.logprobs or params.prompt_logprobs, then forwards those fields into EngineCoreSamplingParams without consulting the model or server max_logprobs setting (default 20) and without a checked unsigned-to-signed conversion. The Python SamplingParams path, by contrast, rejects negative logprob counts other than -1 and rejects counts above model_config.max_logprobs, so the same request via the Python API would raise VLLMValidationError before execution. Because the Rust frontend constructs engine-facing sampling state directly, untrusted counts reach the lower V1 sampler, where torch.topk(logits, num_logprobs, dim=-1) is invoked after an assert num_logprobs >= 0; oversized counts can exhaust memory or raise, and the wraparound value becomes an invalid negative count, either of which surfaces as an uncaught worker exception that EngineCore treats as fatal. This is CWE-20 improper input validation, compounded by CWE-190 integer wraparound and CWE-400 uncontrolled resource consumption. The advisory explicitly distinguishes this from GHSA-6pgw-f3pv-4h8q (token_ids lowering), GHSA-w2v2-5662-8v5q (out-of-vocabulary prompt token IDs) and GHSA-3mwp-wvh9-7528 (OpenAI n fan-out), and notes that public PR #44680 identified top_logprobs/prompt_logprobs as the same DoS class requiring max_logprobs wiring.
Know when Vllm gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
A single crafted gRPC request deterministically triggers the crash (AC:L, no special conditions), the endpoint is unauthenticated by default (PR:N), and the sole impact is engine termination (A:H, C/I:N).
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
2DescriptionCVE.org
vLLM from 0.22.0 before 0.24.0 contains an improper input validation vulnerability in the Rust gRPC converter that allows remote attackers to bypass max_logprobs limits via CandidateTokens.top_n. Attackers can send Generate or GenerateStream requests with oversized or integer-wrapping top_n values to trigger torch.topk failures that terminate EngineCore.
Technical POC Analysis
CWE-20 (Improper Input Validation), with CWE-190 (integer wraparound) and CWE-400 (uncontrolled resource consumption) as the downstream consequences.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
A high-severity availability flaw in vLLM versions 0.22.0 through 0.23.x allows an unauthenticated remote attacker to crash the inference service with a single request, impacting any organization running these versions with the Rust gRPC frontend exposed. Leadership should prioritize remediation because service downtime can disrupt AI-dependent operations and customer-facing services, though no data breach or code execution risk is present.
No vendor-released patch identified at time of analysis. Interim mitigations: restrict network access to the Rust gRPC frontend (Generate/GenerateStream) to trusted clients only; disable the Rust gRPC frontend and rely on the Python or OpenAI-compatible API, which are not reachable through this vector; deploy a reverse proxy or API gateway to enforce strict input validation and request size limits; monitor for abnormal requests that set top_n parameters to extreme values.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
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
Timing-based API key recovery in vLLM before 0.11.0rc2 can let remote attackers bypass bearer-token authentication on de
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated high severity (CVSS 7.5), th
Denial of service in the vLLM LLM inference server (all versions prior to 0.24.0) allows a remote client to crash the sh
vLLM before version 0.14.1 contains a server-side request forgery vulnerability in the MediaConnector class where incons
Out-of-memory worker crashes in vLLM can be induced by a single small compressed audio payload submitted to the /v1/chat
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated medium severity (CVSS 6.5),
GPU memory exhaustion in vLLM versions prior to 0.28.0 lets an attacker with low-privileged API access (PR:L in the CVSS
Multimodal inference requests to vLLM deployments running versions prior to 0.28.0 can trigger a process-level assertion
Uncontrolled resource consumption in vLLM's OpenAI-compatible completions endpoint allows any authenticated API client t
Exploit-DB