CVE-2026-37237: vLLM Memory Exhaustion DoS Vulnerability

CVE-2026-37237 Overview

CVE-2026-37237 is a denial-of-service vulnerability in vLLM versions up to and including 0.17.0. The flaw resides in the AsyncMediaIO.fetch_audio and AsyncMediaIO.fetch_image functions inside multimodal/inputs.py. These functions fetch user-supplied media URLs using aiohttp and invoke r.read() without enforcing a maximum response size. Remote attackers can submit a URL pointing to an arbitrarily large file, forcing the server to buffer the entire payload in memory. Sustained requests exhaust available memory and terminate the inference service. The vulnerability is classified under CWE-400: Uncontrolled Resource Consumption.

Critical Impact
Unauthenticated remote attackers can exhaust vLLM server memory by supplying URLs to arbitrarily large media files, causing service outages for AI inference workloads.

Affected Products

vLLM versions up to and including 0.17.0
Deployments exposing multimodal endpoints that accept remote media URLs
AI inference services built on the vLLM multimodal/inputs.py fetch path

Discovery Timeline

2026-08-28 - CVE-2026-37237 published to NVD
2026-08-28 - Last updated in NVD database

Technical Details for CVE-2026-37237

Vulnerability Analysis

vLLM is a high-throughput inference and serving engine for large language models, including multimodal models that accept image and audio inputs. The multimodal input pipeline supports remote media retrieval so that clients can reference content by URL rather than uploading raw bytes. This design shifts fetch responsibility to the server process.

The AsyncMediaIO helper performs remote fetches using aiohttp. Both fetch_audio and fetch_image call r.read() on the response object. r.read() buffers the entire response body into memory before returning. Without a size limit or streaming boundary, a malicious URL that serves a multi-gigabyte payload will force the worker to allocate matching memory. Repeated or parallel requests amplify the effect and can trigger OOM termination of the inference process.

Root Cause

The root cause is missing enforcement of a maximum response size on server-initiated HTTP fetches. The code path trusts the remote content-length and reads the full body in a single call. There is no cap tied to configuration, no chunked streaming with a byte counter, and no early abort when the payload exceeds a reasonable multimodal input threshold.

Attack Vector

Exploitation requires only network access to the vLLM inference endpoint and the ability to submit a multimodal request that includes a media URL. The attacker hosts a large file, or a slow endless stream, at an HTTP(S) URL and passes that URL as an image or audio input. The vLLM server fetches the file with r.read() and buffers it entirely. No authentication, user interaction, or elevated privileges are required. The upstream fix is tracked in vLLM Pull Request #36506.

No verified proof-of-concept code is published. See the vLLM multimodal inputs source for the affected functions.

Detection Methods for CVE-2026-37237

Indicators of Compromise

Sudden growth in resident memory of vLLM worker processes correlated with inbound multimodal requests referencing external URLs.
Out-of-memory kills or container restarts on GPU inference nodes shortly after receiving requests with remote image_url or audio_url fields.
Outbound HTTP(S) fetches from vLLM hosts to unfamiliar or attacker-controlled domains returning very large content-length values.

Detection Strategies

Inspect vLLM access logs and request bodies for multimodal inputs that reference remote URLs, and correlate with process memory metrics.
Monitor egress traffic from inference nodes for anomalous large-object downloads originating from the vLLM service account.
Alert on repeated container OOM events or Kubernetes pod restarts for pods running vLLM 0.17.0 or earlier.

Monitoring Recommendations

Export vLLM worker memory and request-latency metrics to a centralized observability stack and set thresholds for rapid allocation spikes.
Track HTTP response sizes for server-initiated fetches from AsyncMediaIO code paths.
Log the full set of media URLs submitted per client identity to support post-incident review.

How to Mitigate CVE-2026-37237

Immediate Actions Required

Upgrade vLLM to a release that includes the fix from Pull Request #36506 once available in a tagged version above 0.17.0.
Restrict which clients can reach multimodal endpoints by placing vLLM behind an authenticated API gateway.
Disable or block remote URL inputs for image and audio modalities where the deployment does not require them.

Patch Information

The upstream fix is proposed in vLLM Pull Request #36506, which introduces a maximum response size on media fetches. Operators should track the vLLM release notes and upgrade to the first tagged version that merges this change. Additional context is available at the CVE-2026-37237 write-up.

Workarounds

Place an egress proxy in front of vLLM that enforces a hard content-length limit and rejects oversized media downloads.
Configure container memory limits and per-request timeouts so that a single fetch cannot exhaust the host.
Require clients to upload media inline as base64 or multipart bytes, then reject requests containing remote URLs at the ingress layer.

bash

# Example NGINX egress restriction for vLLM outbound media fetches
http {
    proxy_max_temp_file_size 0;
    client_max_body_size 20m;

    server {
        listen 3128;
        location / {
            proxy_pass $scheme://$host$request_uri;
            proxy_buffering off;
            proxy_read_timeout 10s;
            # Reject responses larger than 20MB
            proxy_intercept_errors on;
            error_page 413 = @toolarge;
        }
        location @toolarge {
            return 413 "media exceeds allowed size";
        }
    }
}