AI Threat AlertCVE-2026-37237: vLLM: unbounded media URLs cause memory-exhaustion DoS
HIGHvLLM's multimodal media fetcher (AsyncMediaIO.fetch_audio/fetch_image) downloads user-supplied image or audio URLs into memory without enforcing any maximum response size, so a single request pointing to an arbitrarily large or endlessly-streaming file can exhaust host memory and crash the inference process. This is a network-exploitable, unauthenticated, zero-complexity bug (CVSS 7.5, AV:N/AC:L/PR:N/UI:N) affecting availability only — no data confidentiality or integrity impact — but any vLLM deployment exposing vision or audio inputs (e.g. OpenAI-compatible chat completions with image_url/audio parameters) is exposed to trivial denial of service. There is no EPSS score, CISA KEV listing, public exploit, or Nuclei template yet, so opportunistic mass exploitation hasn't been observed, but the attack requires no AI/ML expertise and can be reproduced with a single crafted URL, so treat proof-of-concept availability as a matter of time rather than a mitigating factor. Track the upstream fix in vllm-project/vllm PR #36506 and upgrade past 0.17.0 once a patched release ships; in the interim, restrict or proxy outbound media fetches with a hard size cap and monitor inference-host memory for OOM kills on multimodal endpoints.
What is the risk?
High severity by CVSS (7.5) but availability-only impact — confidentiality and integrity are unaffected. Attack complexity is low and requires no privileges or user interaction, making this trivial to exploit for anyone who can reach a vLLM multimodal endpoint (public-facing or internal-but-untrusted). No EPSS percentile, CISA KEV entry, public PoC, or Nuclei template currently exists, so there's no evidence of active or automated exploitation today — but the simplicity of the attack (one malicious URL, no auth bypass or code execution needed) means the barrier to a working exploit is minimal. Risk is elevated for multi-tenant or shared inference deployments, where one attacker's request can deny service to all other users of the same vLLM instance.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| vLLM | pip | — | No patch |
Do you use vLLM? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 stepUpgrade vLLM past 0.17.0 once a release incorporating the fix in PR #36506 is published; track vllm-project/vllm release notes. As an interim workaround, disable URL-based multimodal inputs and require pre-uploaded/base64-encoded media instead, or front the service with a reverse proxy (nginx/Envoy) that enforces a strict maximum response size and timeout on any outbound media fetch. If URL fetching must remain enabled, restrict it to an allowlist of trusted media domains and add custom middleware that streams the response and aborts once a size threshold is exceeded, rather than buffering with
r.read(). For detection, monitor vLLM process/container memory and OOM-kill events on multimodal endpoints, log inbound media URLs and response sizes, and rate-limit multimodal requests per API key/IP to cap the blast radius of repeated attempts.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-37237?
vLLM's multimodal media fetcher (AsyncMediaIO.fetch_audio/fetch_image) downloads user-supplied image or audio URLs into memory without enforcing any maximum response size, so a single request pointing to an arbitrarily large or endlessly-streaming file can exhaust host memory and crash the inference process. This is a network-exploitable, unauthenticated, zero-complexity bug (CVSS 7.5, AV:N/AC:L/PR:N/UI:N) affecting availability only — no data confidentiality or integrity impact — but any vLLM deployment exposing vision or audio inputs (e.g. OpenAI-compatible chat completions with image_url/audio parameters) is exposed to trivial denial of service. There is no EPSS score, CISA KEV listing, public exploit, or Nuclei template yet, so opportunistic mass exploitation hasn't been observed, but the attack requires no AI/ML expertise and can be reproduced with a single crafted URL, so treat proof-of-concept availability as a matter of time rather than a mitigating factor. Track the upstream fix in vllm-project/vllm PR #36506 and upgrade past 0.17.0 once a patched release ships; in the interim, restrict or proxy outbound media fetches with a hard size cap and monitor inference-host memory for OOM kills on multimodal endpoints.
Is CVE-2026-37237 actively exploited?
No confirmed active exploitation of CVE-2026-37237 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-37237?
Upgrade vLLM past 0.17.0 once a release incorporating the fix in PR #36506 is published; track vllm-project/vllm release notes. As an interim workaround, disable URL-based multimodal inputs and require pre-uploaded/base64-encoded media instead, or front the service with a reverse proxy (nginx/Envoy) that enforces a strict maximum response size and timeout on any outbound media fetch. If URL fetching must remain enabled, restrict it to an allowlist of trusted media domains and add custom middleware that streams the response and aborts once a size threshold is exceeded, rather than buffering with `r.read()`. For detection, monitor vLLM process/container memory and OOM-kill events on multimodal endpoints, log inbound media URLs and response sizes, and rate-limit multimodal requests per API key/IP to cap the blast radius of repeated attempts.
What systems are affected by CVE-2026-37237?
This vulnerability affects the following AI/ML architecture patterns: model serving, agent frameworks.
What is the CVSS score for CVE-2026-37237?
CVE-2026-37237 has a CVSS v3.1 base score of 7.5 (HIGH). The EPSS exploitation probability is 0.73%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0029Denial of AI ServiceAML.T0034.001Resource-Intensive QueriesAML.T0049Exploit Public-Facing ApplicationCompliance Controls Affected
What are the technical details?
Original Advisory
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.
Exploitation Scenario
An attacker with access to a vLLM-served vision or audio model sends a single chat-completion request embedding an `image_url` (or audio URL) that points to an attacker-controlled server returning either a multi-gigabyte file or an endless/never-terminating stream with no Content-Length. AsyncMediaIO.fetch_image/fetch_audio calls aiohttp's `r.read()` without any size cap, buffering the entire response into process memory. A handful of such requests — or even one sufficiently large payload — exhausts available memory, causing the vLLM process to be OOM-killed and denying inference service to every other user sharing that deployment, with no authentication or prior access required.
Weaknesses (CWE)
CWE-400 — Uncontrolled Resource Consumption: The product does not properly control the allocation and maintenance of a limited resource.
- [Architecture and Design] Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
- [Architecture and Design] Mitigation of resource exhaustion attacks requires that the target system either: The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker. recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
Timeline
Related Vulnerabilities
CVE-2026-6173210.0Decepticon: ChatML token injection yields sandbox RCE
Same package: vllmCVE-2026-259609.8vllm: SSRF allows internal network access
Same package: vllmCVE-2025-472779.8vLLM: RCE via exposed TCPStore in distributed inference
Same package: vllmCVE-2024-110419.8vllm: RCE via unsafe pickle deserialization in MessageQueue
Same package: vllmCVE-2024-90539.8vllm: RCE via unsafe pickle deserialization in RPC server
Same package: vllm