CVE-2026-116172 in vLLM
Summary
by MITRE • 10/25/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/25/2026
The vLLM framework, specifically versions ranging from 0.22.0 up to but not including 0.24.0, contains a critical improper input validation vulnerability within its Rust-based gRPC converter component. This flaw arises from insufficient sanitization and boundary checking of the top_n parameter found in CandidateTokens structures during request processing. The vulnerability allows remote attackers to manipulate this integer field with oversized values or integers that cause wrapping behavior when processed by underlying computational libraries, specifically PyTorch's torch.topk function. By exploiting this lack of validation, an attacker can effectively bypass configured max_logprobs limits which are designed to restrict the number of log probabilities returned for each token generation step.
From a technical perspective, the root cause lies in the translation layer between the gRPC interface and the internal Python-based inference engine. When a Generate or GenerateStream request is received, the Rust converter parses the CandidateTokens object but fails to enforce strict upper bounds on the top_n field before passing it downstream. If an attacker submits a value that exceeds the expected integer range for torch.topk, or one that causes arithmetic overflow during internal calculations, it triggers a runtime exception within PyTorch. This unhandled exception propagates up through the EngineCore component, leading to its immediate termination and subsequent crash of the inference service instance.
The operational impact of this vulnerability is severe, primarily manifesting as a Denial of Service against vLLM deployments. Because the exploit requires only sending malformed requests with specific integer values in top_n fields, it can be executed remotely by any actor who has network access to the gRPC endpoint. The resulting crash disrupts service availability for all users relying on that instance. Furthermore, while the primary impact is denial of service, the ability to bypass max_logprobs limits could potentially allow attackers to extract more detailed internal model confidence scores than intended, although the immediate and most reliable consequence remains the destabilization of the serving infrastructure through process termination.
This vulnerability aligns with CWE-20 Improper Input Validation as it involves failing to verify that user-supplied input meets expected constraints before processing. In terms of offensive security frameworks, this behavior is consistent with ATT&CK technique T1498 Network Denial of Service, specifically the sub-category of resource exhaustion via application layer attacks where malformed inputs cause service crashes rather than simple bandwidth saturation.
To mitigate this risk, organizations running vLLM in production environments must upgrade to version 0.24.0 or later, which includes patches for input validation within the Rust gRPC converter. Until an upgrade is feasible, administrators should implement network-level controls such as rate limiting and strict payload size restrictions on the gRPC endpoints to prevent oversized requests from reaching the application layer. Additionally, deploying a reverse proxy with deep packet inspection capabilities can help filter out malformed protobuf messages containing invalid integer ranges for top_n fields before they interact with the vulnerable converter component.