Description

vLLM versions before 0.29.0 contain a denial-of-service vulnerability in the cache_salt parameter accepted on OpenAI-compatible and Anthropic API endpoints, which lacks maximum length validation and is processed on the single EngineCore scheduler thread. Unauthenticated attackers can send HTTP requests with multi-hundred-megabyte salt values that trigger expensive pickle serialization and SHA-256 hashing, stalling the scheduler thread and denying service to all concurrent requests.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-09-26T14:16:47.097Z",
  "pubdate": "2026-09-26T14:16:47.097Z",
  "executiveSummary": "vLLM versions prior to 0.29.0 are susceptible to a Denial-of-Service (DoS) vulnerability originating from improper input validation within the API request handling logic. The issue resides in the cache_salt parameter, which is accepted by both OpenAI-compatible and Anthropic API endpoints.\nThe vulnerability allows unauthenticated, remote attackers to trigger resource exhaustion by submitting maliciously crafted HTTP requests containing excessively large salt values. Because the affected parameter is processed directly on the EngineCore scheduler thread, the subsequent computational overhead effectively blocks the event loop.\nThis architectural flaw impacts the availability of the vLLM inference server, as the single-threaded nature of the scheduler prevents concurrent request processing during the execution of expensive operations. Successful exploitation results in a complete cessation of service for all legitimate users. The impact is significant for production environments where high availability is required for model inference. No authentication or elevated privileges are required to initiate this attack, making it a critical risk for internet-exposed vLLM instances.",
  "technicalDetails": "The root cause of this vulnerability is a lack of boundary validation (maximum length constraints) on the cache_salt parameter passed to the request handler. vLLM uses a single-threaded EngineCore scheduler to manage inference requests and underlying GPU/system resources. When a request is received, the input parameters are processed synchronously within this thread.\nThe attack flow begins when an attacker transmits an HTTP request featuring a multi-hundred-megabyte string within the cache_salt field. Upon receipt, the application attempts to process this value using CPU-intensive operations, specifically pickle serialization and SHA-256 hashing. Because the EngineCore scheduler is single-threaded, it becomes exclusively occupied with these operations until they complete.\nThe exploitation process follows these steps: 1) The attacker constructs an HTTP request targeting an OpenAI-compatible or Anthropic API endpoint. 2) The attacker populates the cache_salt parameter with a payload exceeding hundreds of megabytes in size. 3) The vLLM server receives the request and parses the oversized parameter. 4) The application invokes the serialization (pickle) and hashing (SHA-256) routines on the malicious input. 5) Due to the significant computational complexity and the synchronous nature of the execution, the scheduler thread enters a blocked state.\nDuring this period of blocking, the server is unable to accept, process, or dispatch any new inference tasks, effectively stalling the entire vLLM engine. Because these operations occur on the primary scheduler thread, the service becomes unresponsive to all other concurrent clients until the processing of the malicious salt concludes or the process encounters a timeout-related crash. This behavior represents a significant architectural bottleneck that can be weaponized to achieve persistent denial of service. The vulnerability affects all vLLM deployments prior to version 0.29.0 that expose these specific API endpoints to network traffic. The exposure is global for any instance reachable over a network protocol (HTTP/HTTPS) without intermediate request length filtering or WAF protection."
}