CVE-2026-55646: Vllm Vllm DoS Vulnerability

CVE-2026-55646 Overview

CVE-2026-55646 affects vLLM, an open-source inference and serving engine for large language models. The vulnerability exists in the /v1/audio/transcriptions and /v1/audio/translations API routes across versions 0.22.0 through 0.23.0. These endpoints call request.file.read() to fully load an uploaded audio file into memory before the VLLM_MAX_AUDIO_CLIP_FILESIZE_MB size check runs during speech-to-text preprocessing. An authenticated API caller can submit an oversized multipart upload, forcing vLLM to allocate memory proportional to the file size before rejecting the request. This creates memory pressure or process termination depending on deployment resource limits. The issue is fixed in version 0.24.0.

Critical Impact
An authenticated attacker with access to the audio transcription or translation endpoints can trigger memory exhaustion and denial of service against vLLM inference servers by submitting oversized audio uploads.

Affected Products

vLLM versions 0.22.0 through 0.23.0
/v1/audio/transcriptions API route
/v1/audio/translations API route

Discovery Timeline

2026-07-06 - CVE-2026-55646 published to NVD
2026-07-07 - Last updated in NVD database

Technical Details for CVE-2026-55646

Vulnerability Analysis

The vulnerability is a resource exhaustion issue classified under [CWE-400]. The affected code path in vLLM's speech-to-text API handler reads the entire uploaded file into memory before size validation occurs. The documented VLLM_MAX_AUDIO_CLIP_FILESIZE_MB environment variable defaults to 25 MB, but this limit is enforced too late in the request lifecycle. An attacker who can reach the audio endpoints can send multipart uploads far exceeding this limit and consume server memory during the read operation.

Root Cause

The root cause is improper ordering of input validation. The handler invokes request.file.read() to materialize the full upload before checking the file size against the configured maximum. Reading first and validating later defeats the purpose of the size limit for oversized payloads. The fix introduces a chunked read helper, read_upload_with_limit, which inspects the Content-Length header when available and streams data in 64 KiB chunks, aborting as soon as the accumulated size exceeds the configured limit.

Attack Vector

Exploitation requires network access to the vLLM API and privileges sufficient to reach the audio routes. An attacker sends an HTTP multipart POST request containing an oversized audio payload to /v1/audio/transcriptions or /v1/audio/translations. The server allocates memory proportional to the payload size before rejecting the request. Repeated requests can exhaust memory, trigger the OOM killer, or terminate the vLLM process.

python

# Security patch: vllm/entrypoints/speech_to_text/base/utils.py
# Enforces audio upload size limit before full file materialization

from fastapi import UploadFile

import vllm.envs as envs
from vllm.exceptions import VLLMValidationError
from vllm.utils.mem_constants import KiB_bytes, MiB_bytes

_READ_CHUNK_SIZE = 64 * KiB_bytes


async def read_upload_with_limit(
    file: UploadFile,
    max_size_mb: float | None = None,
) -> bytes:
    """Read an uploaded file enforcing a size limit *before* full
    materialization.

    The function first checks the Content-Length header (``file.size``) when
    available.  Regardless, it then performs a chunked read that stops as soon
    as the accumulated bytes exceed the limit, ensuring that an oversized
    upload never fully materializes in memory.
    """

Source: vLLM GitHub Commit b997071

Detection Methods for CVE-2026-55646

Indicators of Compromise

HTTP POST requests to /v1/audio/transcriptions or /v1/audio/translations with Content-Length values significantly exceeding 25 MB.
Repeated 413 or rejected multipart upload responses from vLLM instances immediately preceding process termination.
Sudden vLLM worker memory spikes correlated with inbound audio API traffic.
OOM killer entries in system logs targeting the vLLM process.

Detection Strategies

Monitor request sizes at the reverse proxy or ingress layer for audio transcription endpoints and alert on payloads exceeding the configured VLLM_MAX_AUDIO_CLIP_FILESIZE_MB value.
Correlate API access logs with container or host memory metrics to detect memory growth tied to specific client IPs.
Track vLLM process restarts and worker crash counts as a downstream signal of exploitation attempts.

Monitoring Recommendations

Enable request-size logging on the API gateway fronting vLLM to capture multipart upload dimensions.
Deploy resource-usage alerting on vLLM containers with thresholds tied to expected inference workload baselines.
Aggregate access logs into a centralized analytics platform to identify authenticated clients issuing anomalously large audio uploads.

How to Mitigate CVE-2026-55646

Immediate Actions Required

Upgrade vLLM to version 0.24.0 or later, which contains the read_upload_with_limit chunked-read fix.
Restrict network access to the /v1/audio/transcriptions and /v1/audio/translations routes to trusted clients only.
Enforce upload size limits at the reverse proxy or API gateway in front of vLLM as a defense-in-depth measure.
Apply container memory limits so that a single oversized request cannot destabilize the host.

Patch Information

The fix is delivered in vLLM version 0.24.0 via GitHub Pull Request #45510 and commit b997071. The patch introduces a shared read_upload_with_limit helper in vllm/entrypoints/speech_to_text/base/utils.py that validates the Content-Length header and performs a chunked read that aborts once the configured limit is exceeded. Additional details are available in the GitHub Security Advisory GHSA-v82g-2437-67m2.

Workarounds

Configure the fronting reverse proxy (for example, NGINX client_max_body_size) to reject multipart uploads larger than the intended audio clip size before they reach vLLM.
Disable the audio transcription and translation endpoints if the deployment does not require speech-to-text functionality.
Require authentication and rate limiting on the vLLM API surface to reduce the population of callers able to reach the vulnerable routes.

bash

# NGINX configuration example limiting audio upload size upstream of vLLM
http {
    client_max_body_size 25m;

    server {
        location /v1/audio/ {
            client_max_body_size 25m;
            proxy_pass http://vllm_backend;
        }
    }
}