CVE-2026-54233: Vllm Vllm DOS Vulnerability

CVE-2026-54233 Overview

CVE-2026-54233 affects vLLM, an inference and serving engine for large language models (LLMs). The vulnerability resides in the /v1/audio/transcriptions endpoint, which enforces a size limit on compressed audio uploads but fails to validate the size of decoded Pulse Code Modulation (PCM) output. An authenticated attacker can submit a small compressed OPUS file that expands dramatically during decoding, exhausting host memory. A 25MB OPUS upload decodes to approximately 14.9GB of float32 PCM data. The issue is tracked as [CWE-409] (Improper Handling of Highly Compressed Data) and is resolved in version 0.23.1rc0.

Critical Impact
A network-accessible attacker with low privileges can trigger memory exhaustion on the vLLM server, causing denial of service for all hosted inference workloads.

Affected Products

vLLM versions prior to 0.23.1rc0
Deployments exposing the /v1/audio/transcriptions endpoint
Inference services accepting OPUS or other compressed audio formats

Discovery Timeline

2026-06-22 - CVE-2026-54233 published to NVD
2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-54233

Vulnerability Analysis

The vulnerability is a decompression bomb in vLLM's audio transcription pipeline. The /v1/audio/transcriptions endpoint validates the byte length of incoming compressed audio uploads but does not validate the size of the resulting raw audio buffer after decoding. Compressed audio codecs such as OPUS achieve very high compression ratios for silence or low-entropy signals. When vLLM decodes the upload into float32 PCM samples, the in-memory representation can exceed the compressed payload by three orders of magnitude.

In the reported case, a 25MB OPUS file expands to roughly 14.9GB of float32 PCM data. Servers running vLLM typically run on GPU hosts with finite system memory, and allocating this volume of audio data triggers out-of-memory conditions. The Python worker process can be killed by the operating system, terminating concurrent inference requests.

Root Cause

The root cause is missing post-decode size validation. The endpoint accepts arbitrary compressed audio within a configured upload limit but never bounds the decoded sample count or duration. Float32 PCM at 48kHz sample rate consumes approximately 192KB per second per channel, so silence-padded OPUS streams produce extreme expansion ratios.

Attack Vector

The attack vector is network-based and requires low-privilege authenticated access to the vLLM API. An attacker crafts an OPUS file containing long silent or low-entropy regions, then submits it to the transcription endpoint. The decode operation consumes available host memory and the worker process terminates, denying service to legitimate users. Repeated submissions sustain the denial-of-service condition.

No public proof-of-concept exploit code is available. See the GitHub Security Advisory GHSA-6pr9-rp53-2pmc for vendor technical details.

Detection Methods for CVE-2026-54233

Indicators of Compromise

Sudden out-of-memory (OOM) kills of vLLM worker processes in system logs (dmesg, journalctl).
HTTP POST requests to /v1/audio/transcriptions with small payloads followed by extended processing time or 5xx responses.
Spikes in resident set size (RSS) of the vLLM Python process immediately after transcription requests.

Detection Strategies

Monitor request-to-response latency on the /v1/audio/transcriptions endpoint and alert on anomalous decode duration.
Inspect HTTP access logs for repeated audio uploads from a single authenticated identity within short windows.
Correlate memory utilization metrics with API request traces to identify decode-time amplification.

Monitoring Recommendations

Export vLLM process metrics (memory, CPU, file descriptors) to a centralized observability platform.
Track Linux kernel OOM-killer events targeting Python and vLLM worker processes.
Enable audit logging on the inference API gateway to capture authenticated client identities and payload sizes.

How to Mitigate CVE-2026-54233

Immediate Actions Required

Upgrade vLLM to version 0.23.1rc0 or later, which enforces decoded PCM size limits.
Restrict access to the /v1/audio/transcriptions endpoint to trusted authenticated clients only.
Place a reverse proxy in front of vLLM to enforce per-client request rate limits and payload caps.

Patch Information

The vulnerability is fixed in vLLM 0.23.1rc0. Review the upstream fix in vLLM Pull Request #44970 and the GitHub Security Advisory GHSA-6pr9-rp53-2pmc for implementation details.

Workarounds

Disable the audio transcription endpoint at the reverse proxy if not required for the deployment.
Cap maximum audio duration accepted by upstream validators before requests reach vLLM.
Deploy vLLM workers in containers with hard memory limits to contain blast radius from OOM events.

bash

# Configuration example: upgrade vLLM and enforce reverse-proxy payload limits
pip install --upgrade "vllm>=0.23.1rc0"

# Example NGINX directives in front of vLLM
# location /v1/audio/transcriptions {
#     client_max_body_size 1m;
#     limit_req zone=transcribe burst=5 nodelay;
#     proxy_pass http://vllm_backend;
# }