What is the CVSS score of CVE-2026-54233?

CVE-2026-54233 has a CVSS 3.1 base score of 6.5 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.3%.

Is there a patch available for CVE-2026-54233?

Yes, a patch is available for CVE-2026-54233. Update the affected software to the latest version immediately.

vLLM CVE-2026-54233

Q: Which versions of vLLM are affected by CVE-2026-54233?

Memory exhaustion via audio decompression bomb in vLLM's `/v1/audio/transcriptions` endpoint allows a remote attacker to crash or severely degrade the inference server by uploading a crafted OPUS…. A patch is available.

MEDIUM

Improper Handling of Highly Compressed Data (Data Amplification) (CWE-409)

2026-06-17 https://github.com/vllm-project/vllm

GHSA-6pr9-rp53-2pmc

Python Information Disclosure Red Hat

6.5

CVSS 3.1 · Vendor: https://github.com/vllm-project/vllm

Severity by source

Vendor (https://github.com/vllm-project/vllm) PRIMARY

6.5 MEDIUM

AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

vuln.today AI

7.5 HIGH

vLLM enforces no native authentication; advisory explicitly states unauthenticated access, warranting PR:N over the official PR:L; impact is pure availability with no confidentiality or integrity effect.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Red Hat

6.5 MEDIUM

qualitative

Primary rating from Vendor (https://github.com/vllm-project/vllm).

CVSS VectorVendor: https://github.com/vllm-project/vllm

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

Jun 18, 2026 - 01:45 vuln.today

Analysis Generated

Jun 18, 2026 - 01:45 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

2 pypi packages depend on vllm (2 direct, 0 indirect)

Ecosystem-wide dependent count for version 0.23.0.

DescriptionCVE.org

Summary

vLLM's /v1/audio/transcriptions endpoint limits compressed upload size but not decoded PCM output. A 25MB OPUS file expands to ~14.9GB of float32 PCM at decode time. Tested on vLLM v0.19.0.

Details

SpeechToTextProcessor rejects uploads over VLLM_MAX_AUDIO_CLIP_FILESIZE_MB (default 25MB) based on compressed byte length, but the audio decoder in audio.py accumulates all decoded frames into memory with no size limit before returning:

python

# speech_to_text.py L184-189
if len(audio_data) / 1024 ** 2 > self.max_audio_filesize_mb:
    raise VLLMValidationError(...)
y, sr = load_audio(buf, sr=self.asr_config.sample_rate)
# decoded size unchecked
# audio.py L77-107
chunks: list[npt.NDArray] = []
for frame in container.decode(stream):
    chunks.append(frame.to_ndarray())
audio = np.concatenate(chunks, axis=-1).astype(np.float32)
# single contiguous allocation

A 25MB OPUS file at 6kbps encodes ~8.7 hours of audio. Decoding produces ~5.7GB of float32 PCM (232x amplification), and np.concatenate then allocates a second contiguous array, bringing peak RSS to ~14.9GB from a single request. SpeechToTextConfig.max_audio_clip_s (default 30s) applies only after the full decode and does not prevent the allocation.

Impact

An unauthenticated attacker can exhaust server memory with a small number of concurrent requests, each a valid upload within the documented size limit. Severity was assessed with reference to prior OOM vulnerability reports in vLLM.

Fix

A fix for this vulnerability was merged here: https://github.com/vllm-project/vllm/pull/44970

AnalysisAI

Memory exhaustion via audio decompression bomb in vLLM's /v1/audio/transcriptions endpoint allows a remote attacker to crash or severely degrade the inference server by uploading a crafted OPUS file that passes the 25MB compressed-size check but decodes to ~14.9GB of float32 PCM in memory. Affected are vLLM installations through v0.23.0 with speech-to-text (ASR) functionality enabled. No public exploit code has been identified at time of analysis and the vulnerability is not listed in CISA KEV; however, the attack methodology is fully detailed in GitHub Security Advisory GHSA-6pr9-rp53-2pmc, making independent reproduction trivial. The official CVSS PR:L rating conflicts with the advisory's explicit claim of unauthenticated exploitation - security teams should audit whether their deployment enforces authentication on the audio endpoint.

Technical ContextAI

CWE-409 (Improper Handling of Highly Compressed Data - Decompression Bomb) is the root cause. The affected package is pip/vllm <= 0.23.0. The SpeechToTextProcessor in speech_to_text.py correctly rejects uploads exceeding VLLM_MAX_AUDIO_CLIP_FILESIZE_MB (default 25MB) by checking the compressed byte length before decoding. However, load_audio() in vllm/multimodal/media/audio.py uses PyAV's container.decode(stream) in a loop, appending each decoded frame's NumPy array to a Python list, then calls np.concatenate() on the entire list - this allocates a second, contiguous array, doubling peak RSS. The SpeechToTextConfig.max_audio_clip_s duration guard (default 30s) is applied only after full decode, providing no memory protection. OPUS at 6kbps achieves a ~232x decompression ratio: a 25MB file encodes ~8.7 hours of audio, yielding ~5.7GB of decoded PCM frames plus ~9.2GB for the concatenation step, totalling ~14.9GB peak RSS from a single API request.

RemediationAI

Upgrade to vLLM v0.23.1rc0 or a subsequent GA release that incorporates PR #44970 (https://github.com/vllm-project/vllm/pull/44970, commit 1b1359c33269446f13c05da9a90c25174cbea590). The fix introduces the VLLM_MAX_AUDIO_DECODE_DURATION_S environment variable (default 600 seconds) enforced during decode in both the PyAV and soundfile backends - rejection occurs before full memory allocation, either from container metadata inspection or per-frame sample counting, preventing the decompression bomb. Note that v0.23.1rc0 is a release candidate; monitor the vLLM releases page at https://github.com/vllm-project/vllm/releases for the GA version before deploying to production. If patching is not immediately possible, restrict network access to the /v1/audio/transcriptions endpoint via reverse proxy ACL or firewall rules to trusted, authenticated clients only - this is the most effective compensating control but requires deployment changes. Reducing VLLM_MAX_AUDIO_CLIP_FILESIZE_MB to a smaller value (e.g., 1MB) decreases the maximum decompression amplification per request but does not eliminate the vulnerability. Rate-limiting uploads per source IP can slow a sequential attack but does not prevent a burst of concurrent requests.