CVE-2026-116173 in vLLM
Summary
by MITRE • 10/25/2026
vLLM from 0.22.0 before 0.24.0 contains a denial of service vulnerability that allows remote attackers to terminate EngineCore by bypassing logprob_token_ids limits in the Rust gRPC frontend. Attackers can send Generate or GenerateStream requests with output_logprobs enabled and more than 128 output_candidates.token_ids, triggering a fatal sampler exception that crashes the engine.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/25/2026
The vulnerability identified within vLLM versions ranging from 0.22.0 up to but not including 0.24.0 represents a critical denial of service flaw located in the Rust-based gRPC frontend interface. This specific weakness allows remote, unauthenticated attackers to disrupt the availability of large language model inference services by exploiting insufficient input validation mechanisms within the request processing pipeline. The core technical issue stems from the failure to enforce strict bounds checking on the number of output candidates requested during generation tasks. Specifically, when an attacker submits a Generate or GenerateStream RPC call with the output_logprobs flag enabled and specifies more than 128 token IDs in the output_candidates field, the system fails to reject this malformed request prior to execution. Instead, the excessive input propagates deeper into the inference engine where it triggers a fatal exception within the sampler component responsible for calculating log probabilities. This unhandled exception causes the EngineCore process to terminate abruptly, resulting in an immediate and complete loss of service for all users relying on that specific instance or cluster node.
From a technical perspective, this vulnerability is classified under CWE-20 as Improper Input Validation because the application does not adequately sanitize or validate user-supplied data before processing it. The lack of boundary checks allows a single malicious request to consume excessive resources or trigger internal logic errors that crash the host process rather than returning an appropriate error code to the client. In terms of attack classification, this aligns with MITRE ATT&CK technique T1499 Endpoint Denial of Service, specifically under sub-techniques involving resource exhaustion through application layer attacks. The attacker does not need to exploit a memory corruption bug or execute arbitrary code; they simply need to send a well-formed but logically invalid request that exceeds the expected operational limits defined by the software developers. This makes exploitation straightforward and highly reliable for any actor with network access to the gRPC endpoint, regardless of their skill level regarding low-level system exploitation techniques.
The operational impact of this vulnerability is severe due to the critical nature of vLLM in modern AI infrastructure deployments. Since vLLM is often used as a high-throughput serving engine for large language models, its availability is paramount for downstream applications such as chatbots, code generation tools, and data analysis platforms. A successful exploitation results in an immediate service outage that requires manual intervention to restore functionality, typically involving restarting the crashed EngineCore process. In distributed environments or containerized deployments where auto-restart policies might be configured, this could lead to a continuous cycle of crashes and restarts, consuming significant CPU and memory resources without providing any useful computation. This effectively creates a persistent denial of service condition that can degrade performance for legitimate users even if the system eventually recovers, as the overhead of repeated initialization and context loading impacts overall throughput and latency metrics significantly.
Mitigation strategies must focus on both immediate patching and architectural hardening to prevent recurrence. The primary remediation is to upgrade vLLM to version 0.24.0 or later, where this input validation logic has been corrected to enforce the limit of output candidates properly. For environments that cannot immediately update due to compatibility constraints, network-level controls should be implemented to restrict access to the gRPC port exclusively to trusted internal networks using firewalls or service mesh policies. Additionally, implementing rate limiting and request size restrictions at a reverse proxy layer can help mitigate the impact by blocking oversized requests before they reach the vulnerable application logic. Developers integrating vLLM into their pipelines should also implement client-side validation to ensure that generated requests adhere to expected parameter limits, adding an extra layer of defense in depth against malformed inputs originating from compromised or malicious internal services.