Description

vLLM up to and including 0.17.0 allows remote attackers to cause a Denial of Service via memory exhaustion. The AsyncMediaIO.fetch_audio and AsyncMediaIO.fetch_image functions in multimodal/inputs.py fetch user-supplied media URLs using aiohttp and call r.read() without enforcing a maximum response size, allowing an attacker to exhaust server memory by providing a URL to an arbitrarily large file.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-28T16:17:46.300Z",
  "pubdate": "2026-08-28T16:17:46.300Z",
  "executiveSummary": "This vulnerability involves an Improper Resource Shutdown or Release, specifically manifesting as a Denial of Service (DoS) via memory exhaustion in vLLM versions up to and including 0.17.0.\nThe flaw resides in the multimodal processing pipeline, where the system fails to enforce input size constraints when fetching remote media files.\nA remote, unauthenticated attacker can exploit this by providing a maliciously crafted URL pointing to an arbitrarily large file.\nUpon processing the request, the application attempts to buffer the entire remote file into server memory, leading to resource depletion.\nSuccessful exploitation results in the crashing of the vLLM service or system-wide instability due to Out-Of-Memory (OOM) conditions.\nThe risk to availability is critical, as it allows unauthorized users to disrupt production inference services without requiring prior system access or authentication.",
  "technicalDetails": "The vulnerability is located in the multimodal/inputs.py file, specifically within the AsyncMediaIO.fetch_audio and AsyncMediaIO.fetch_image functions.\nThese functions utilize the aiohttp library to perform asynchronous HTTP GET requests for media content provided via user-supplied URLs.\nThe root cause is the invocation of the r.read() method on the response object without implementing any size validation, threshold checks, or streaming limits prior to memory allocation.\nIn the context of the aiohttp implementation, r.read() attempts to load the entire payload of the HTTP response into the process's resident memory.\nBecause the input URL is user-controlled, an attacker can point the service toward a large file hosted on a remote server or a 'decompression bomb' style resource.\nThe attack flow proceeds as follows: First, the attacker submits a request containing a media URL to the vLLM inference endpoint. Second, the AsyncMediaIO handler initiates an aiohttp GET request to the provided URL. Third, the remote server responds, potentially streaming a massive amount of data. Fourth, vLLM consumes this stream via r.read(), forcing the entire payload into RAM.\nAs the process memory usage grows unchecked, the operating system eventually triggers an OOM killer or the application process hits its maximum memory allocation, resulting in a service crash and a loss of availability for all legitimate users.\nThis vulnerability is exploitable remotely over the network, requires no special privileges, and functions without any authentication, as the input processing logic is invoked before subsequent validation layers.\nThe lack of a 'content-length' header verification or an explicit chunked-transfer size limit exacerbates the vulnerability, as the application assumes that all remote responses are benign and fit within available memory segments."
}