CVE-2026-114051 in vLLM
Summary
by MITRE • 10/21/2026
vLLM before 0.31.0 skips the min_tokens <= max_tokens check for /inference/v1/generate requests with a null max_tokens, so the EngineCore input thread later dies on an uncaught VLLMValidationError while /health still returns 200. Unauthenticated remote attackers can send one request with an oversized min_tokens to hang all subsequent generation requests until manual restart.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability in vLLM versions prior to 0.31.0 represents a critical logic error within the inference engine that allows for denial of service through parameter manipulation. Specifically, the system fails to enforce the logical constraint that the minimum number of tokens must be less than or equal to the maximum number of tokens when processing requests via the /inference/v1/generate endpoint where max_tokens is set to null. In these specific scenarios, the validation logic incorrectly assumes a default upper bound or bypasses the check entirely, allowing clients to submit requests with an excessively large min_tokens value that exceeds any implicit system limits. This oversight creates a state inconsistency within the EngineCore input thread, which processes incoming inference tasks and manages resource allocation for model generation.
When such a malformed request is received, the internal validation mechanisms eventually detect the invalid parameter combination during execution rather than at the initial entry point. Consequently, an uncaught VLLMValidationError is thrown deep within the processing pipeline. Because this exception is not properly handled or caught by the surrounding service logic, it causes the EngineCore input thread to terminate abruptly. This crash disrupts the core inference capabilities of the application, effectively halting all subsequent generation requests until the service process is manually restarted. The severity of this issue is compounded by the fact that the /health endpoint continues to return a 200 OK status code even while the engine is in this broken state.
This discrepancy between health check responses and actual operational capability creates a significant risk for automated systems relying on standard monitoring probes. Attackers can exploit this behavior by sending a single, carefully crafted request with an oversized min_tokens parameter to trigger the crash. Since no authentication is required to access these endpoints, unauthenticated remote attackers can easily execute this attack vector from anywhere on the network. The resulting denial of service affects all users and applications depending on the vLLM instance for text generation or other inference tasks, leading to complete service outage until administrative intervention occurs.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the system fails to adequately validate user-supplied input against expected constraints before processing. It also relates to CWE-754: Improper Check for Unusual or Exceptional Conditions, specifically regarding the failure to handle edge cases in parameter validation logic. In terms of attack tactics, this falls under MITRE ATT&CK technique T1499 Endpoint Denial of Service, where an attacker disrupts availability by exhausting resources or crashing services through malformed requests. The lack of authentication further exacerbates the risk profile, classifying it as a high-severity issue due to its ease of exploitation and impact on service continuity.
To mitigate this vulnerability, organizations must upgrade vLLM to version 0.31.0 or later, where the input validation logic has been corrected to properly enforce the min_tokens less than or equal to max_tokens constraint even when max_tokens is null. Until an upgrade can be performed, administrators should implement network-level controls such as web application firewalls that inspect request parameters for suspiciously large integer values in the min_tokens field and block them before they reach the vLLM service. Additionally, configuring health checks to perform more than just a simple HTTP status code check by verifying actual engine responsiveness or running a lightweight test inference can help detect this state of unavailability earlier. Regular patching cycles and strict input validation policies are essential defenses against such logic-based denial of service attacks in machine learning serving infrastructure.